433MHz-communicatie met microcontrollers

[Fuzzillogic]

Verwijderd schreef op vrijdag 03 februari 2012 @ 12:30:
Fuzzillogic:

array_pos=0; Volgens mij is dit de reset ?

Kan jij misschien aangeven waar de reset moet plaats vinden?

Dat is de reset als al geldige data binnen hebt gekregen. Maar je zult al veel vaker moeten resetten, op het moment dat blijkt dat het signaal niet (meer) correct blijkt te zijn. Bij elke pulse zul je dus op de drie genoemde scenario's moeten controleren.

En gebruik ajb [code] blokken voor code, dat leest een heel stuk prettiger

[WVL_KsZeN]

OK, ben dan eindelijk eens begonnen met KaKu, heb nu 2 ontvangers en één zender gekocht. Als volgende wil ik een dimmer die in de muur zit ingebouwd vervangen door ééntje van KaKu, en deze gaan aansturen met een arduino..

Wat wil ik precies :

- KaKu inbouwdimmer in muur inbouwen
- eigen op-arduino-gebaseerde schakelaar/dimmer-zender ergens anders op een muur plakken, zodat ik de ingebouwde dimmer kan bedienen. Op mijn eigen zender wil ik een draaiknop à la jog-wheel, zodat ik dus pulsjes kan verzenden (als in : meer licht, of minder licht).

De ontvanger-dimmer moet dus ofwel een absolute dimstand kunnen ontvangen (dan onthoud mijn zender de huidige dimstand), ofwel signalen als 'minder licht' of 'meer licht' accepteren.

Het is me niet duidelijk welke dimmer van KaKu dit nu precies kan. Misschien dat jullie me kunnen adviseren? Is arduino eigenlijk wel een goede keus als ik iets wil maken dat lang op zijn batterijtje doet (zeg een paar maanden?)

[Verwijderd]

Hey all,

Ik ben dit topic flink aan het rondzoeken geweest maar kan het niet vinden. Ik wil graag sturing van de stopcontacten doen via Arduino. Ik heb hier een arduino uno boardje liggen, maar welk schema, 433 chip hoort hier precies bij? Ik heb niks kunnen vinden!

Thnx alvast

[10ii]

Verwijderd schreef op maandag 06 februari 2012 @ 12:47:
Hey all,

Ik ben dit topic flink aan het rondzoeken geweest maar kan het niet vinden. Ik wil graag sturing van de stopcontacten doen via Arduino. Ik heb hier een arduino uno boardje liggen, maar welk schema, 433 chip hoort hier precies bij? Ik heb niks kunnen vinden!

Thnx alvast

Zie hier. voor een 433 mhz transmitter/ receiver.

Voor aansluit schema/ foto. zie de eerste reactie in dit forum.

[Verwijderd]

Cool! Thnx.

Kan ik deze kit ook gebruiken? Ik zou graag snel aan het testen willen

[10ii]

Verwijderd schreef op woensdag 08 februari 2012 @ 12:10:
Cool! Thnx.

Kan ik deze kit ook gebruiken? Ik zou graag snel aan het testen willen

Zou ook moeten gaan maar om er zeker van te zijn heb je een datasheet of zo nodig.

Ik zou dan eerder deze aanraden, een stuk goedkoper en ik weet zeker dat ze werken:
transmitter
receiver

[Verwijderd]

Ik heb de conrads toch genomen, moest meerbij conrad hebben. @fuzzilogic, is het ook mogelijk om de ruwe ontvangen codes te versturen met jouw library?

dus de ontvangencode: Code: 176654, period duration: 325us. bijvoorbeeld?

[Fuzzillogic]

Verwijderd schreef op zaterdag 11 februari 2012 @ 19:16:
Ik heb de conrads toch genomen, moest meerbij conrad hebben. @fuzzilogic, is het ook mogelijk om de ruwe ontvangen codes te versturen met jouw library?

dus de ontvangencode: Code: 176654, period duration: 325us. bijvoorbeeld?

Ja, dat kan. Zie example "Retransmitter", die precies dat doet

---

Zojuist een update gepusht op de default branch (download). Deze versie is compatible met Arduino 1.0, betrouwbaarder (althans, dat is het idee ) en biedt support voor de Elro-sets. Geen support nog voor new KaKu

[TEAMIKKE]

Verwijderd schreef op zaterdag 05 november 2011 @ 01:46:
Eergisteren ook een paar AtMega's328 en 433 rx/tx binnen gekregen om een arduino in elkaar te steken

Om terug te komen op de Nieuwe KaKu code's:
Op CO vond ik dit topic met timings.

even quick en dirty de onderstaande code (zonder dim) geschreven voor het aansturen van de zender.

C++:

verhaal aan code

Helaas heb ik dit niet werkend gekregen, de hardware werkt probleemloos met Fuzzilogic's Code
Iemand een suggestie?

Heeft iemand hier misschien nog iets over te zeggen? Ik heb zelf ook een dergelijke code geschreven maar dan in picBasic maar ik zie de fout helaas ook niet. Kan iemand wellicht een zetje in de goede richting geven?

Voor de duidelijkheid hangt aan portb.0 een 433mhz zendertje, aan porta.1 een led en verder wordt er gebruikt gemaakt van een extern 20mhz kristal.

code:

Zie hieronder

[ Voor 45% gewijzigd door TEAMIKKE op 26-03-2012 09:17 ]

[Verwijderd]

Ik heb een goedkope Yagi-antenne gebouwd voor 433.92MHz. Als 't iemand interesseert kan ik het ontwerp beschrijven.

[franssie]

Verwijderd schreef op maandag 19 maart 2012 @ 23:27:
Ik heb een goedkope Yagi-antenne gebouwd voor 433.92MHz. Als 't iemand interesseert kan ik het ontwerp beschrijven.

ik ben nog niet erg actief in het 433 spectrum, maar ja, graag! Ben ook erg benieuwd naar de afmetingen.

[memphis]

Afgelopen vrijdag op mijn deurmat:



FM, smalbandig en de high power versie (25mW), goed voor 500 meter bereik bij een zo'n symetrisch mogelijk signaal, met een simpel serieel lijntje zou die op zeker 100 meter moeten kunnen halen.

Ik probeer het eerst met een gewone draadantenne maar als het bereik niet voldoende is zal ik een GP antenne aan de ontvanger proberen. Een 1e test geeft al aardige resultaten.

[TEAMIKKE]

TEAMIKKE schreef op zaterdag 17 maart 2012 @ 17:14:
[...]


Heeft iemand hier misschien nog iets over te zeggen? Ik heb zelf ook een dergelijke code geschreven maar dan in picBasic maar ik zie de fout helaas ook niet. Kan iemand wellicht een zetje in de goede richting geven?

Voor de duidelijkheid hangt aan portb.0 een 433mhz zendertje, aan porta.1 een led en verder wordt er gebruikt gemaakt van een extern 20mhz kristal.

code:

lap code

Met behulp van de timings op de vorige pagina en wat aanwijzing op CO heb ik ondertussen het geheel werkend. Voor de liefhebber post ik nog even de werkende maar spartaanse code. Kan een stuk efficiënter maar het is wel duidelijk wat er gebeurt. Overigens heb ik me nog niet bezig gehouden met de dimfunctie, die zit er nog niet in verwerkt. Ik heb geen ontvangers die daar mee werken. Mooi topic dit, bedankt voor de vele info beschreven

code:

DEVICE 16F628A
CONFIG WDT_OFF, PWRTE_ON, LVP_OFF, MCLRE_OFF, HS_OSC
ALL_DIGITAL TRUE
XTAL 20

; Nieuwe KAKU protocol
;        _   _
; '0' = | |_| |___  (T,T,T,3T)
;        _     _
; '1' = | |___| |_  (T,3T,T,T)
;        _   _
; dim = | |_| |_    (T,T,T,T)
;
; T = 275 us of 375 us
;
; Samenstelling signaal
; 26 adres bits
; 1 groep bit
; 1 on/of/dim bit
; 4 unit bits
; (4 dim bits)
; Stoppuls (T hoog, verder laag)

DIM teller AS BYTE
DIM wachttijd AS WORD

SYMBOL Led1 = PORTA.1         ; Led
SYMBOL Aan_knop = PORTA.2     ; Aan knop
SYMBOL Uit_knop = PORTA.0     ; Uit knop
SYMBOL Zender = PORTB.0       ; Zender

        ;76543210
PORTA = %00000000
PORTB = %00000000

TRISA = %00000101
TRISB = %00000000

wachttijd = 1000

HIGH Led1                     ;opstart loopje
DELAYMS wachttijd
LOW Led1
DELAYMS wachttijd

WHILE 1 = 1                   ;hoofdprogramma

    IF Aan_knop = 0 THEN      ;als de aan knop wordt ingedrukt
        HIGH Led1             ;een aan signaal zenden
            WHILE Aan_knop = 0
            DELAYMS 10
            WEND
       GOSUB sw1aan
       LOW Led1
       DELAYMS 50
    ENDIF


    IF Uit_knop = 0 THEN      ;als de uit knop wordt ingedrukt
        HIGH Led1             ;een uit signaal zenden
            WHILE Uit_knop = 0
            DELAYMS 10
            WEND
        GOSUB sw1uit
       LOW Led1
       DELAYMS 50
    ENDIF

    IF Aan_knop = 0 AND Uit_knop = 0 THEN         ;Als beide knoppen worden ingdrukt
        HIGH Led1                                 ;de zender aanmelden
            WHILE Uit_knop = 0 AND Uit_knop = 0
            DELAYMS 10
            WEND
        GOSUB sw1_aanmelden
       LOW Led1
       DELAYMS 50
    ENDIF

    DELAYMS 10

WEND

;--------------

sw1_aanmelden:
FOR teller = 1 TO 10          ;10x het signaal herhalen
GOSUB sw1aan
NEXT

RETURN

;--------------

sw1aan:                       ;kanaal 1 aanzetten

FOR teller = 1 TO 5

GOSUB startpuls               ;startpuls

GOSUB laag                    ;Adres bestaat uit 26 bits
GOSUB laag
GOSUB laag
GOSUB laag
GOSUB laag
GOSUB laag
GOSUB laag
GOSUB laag

GOSUB laag
GOSUB laag
GOSUB laag
GOSUB laag
GOSUB laag
GOSUB laag
GOSUB laag
GOSUB laag

GOSUB laag
GOSUB laag
GOSUB laag
GOSUB laag
GOSUB laag
GOSUB laag
GOSUB laag
GOSUB laag

GOSUB laag
GOSUB hoog

GOSUB laag                    ;Groepbit

GOSUB hoog                    ;on/off

GOSUB laag                    ;units aanduiding
GOSUB laag
GOSUB laag
GOSUB laag

GOSUB stoppuls                ;Stoppuls

NEXT

RETURN

sw1uit:                       ;kanaal 1 uitzetten
FOR teller = 1 TO 5

GOSUB startpuls               ;startpuls

GOSUB laag                    ;Adres bestaat uit 26 bits
GOSUB laag
GOSUB laag
GOSUB laag
GOSUB laag
GOSUB laag
GOSUB laag
GOSUB laag

GOSUB laag
GOSUB laag
GOSUB laag
GOSUB laag
GOSUB laag
GOSUB laag
GOSUB laag
GOSUB laag

GOSUB laag
GOSUB laag
GOSUB laag
GOSUB laag
GOSUB laag
GOSUB laag
GOSUB laag
GOSUB laag

GOSUB laag
GOSUB hoog

GOSUB laag                    ;Groepbit

GOSUB laag                    ;on/off

GOSUB laag                    ;units aanduiding
GOSUB laag
GOSUB laag
GOSUB laag

GOSUB stoppuls                ;Stoppuls

NEXT

RETURN


;--------------

startpuls:
HIGH Zender
DELAYUS 330
LOW Zender
DELAYUS 2600

RETURN

;--------------

laag:
HIGH Zender
DELAYUS 330
LOW Zender
DELAYUS 200
HIGH Zender
DELAYUS 330
LOW Zender
DELAYUS 1200

RETURN

;--------------

hoog:
HIGH Zender
DELAYUS 330
LOW Zender
DELAYUS 1200
HIGH Zender
DELAYUS 330
LOW Zender
DELAYUS 200

RETURN

;--------------

stoppuls:
HIGH Zender
DELAYUS 330
LOW Zender
DELAYUS 10200

RETURN

;--------------

END

[Fuzzillogic]

Is hier iemand met een scope en een nieuwe kaku-zender die even wat getallen kan bevestigen? Ik heb een sample-space van precies 1 zender en 0 ontvangers. Dat is vrij beperkt. Met een oscilloscoop heb ik de meeste getallen uit deze CO-post grotendeels kunnen verifiëren, met toch enkele verschillen:

1. De periodetijd (1T) is bij mij ~260us. Is dat altijd zo bij kaku? Zijn er klonen met afwijkende timing?
2. Een '0'-bit is T, T, T, 5T, dus totaal 8T
3. Een '1'-bit is T, 5T, T, T, hier dus ook 8T totaal.
4. De start-sequence is bij mij 1T hoog, 10,44T laag. (totaal 2,96ms gemeten) CO meldt hier 1T hoog, 9T laag. Waarom dit geen mooi rond getal wordt is mij een raadsel
5. De stop-sequence is bij mij 1T hoog, 40T laag. (totaal 10,60ms gemeten) CO meldt alleen 1T hoog "lang laag".
6. 'dim' kan ik niet meten, bij gebrek aan hardware.

Deze timings zijn van belang omdat ik bezig ben met een new-kaku-receiver voor in de library (ja echt!). Mocht de periodetijd bij al deze apparaten ~260us zijn dan hoeft er geen periodetijd-detectie te komen en is herkenning betrouwbaarder. Mocht de periodetijd wél variëren, dan moet deze dus bepaald worden, en dan zijn m.n. de start- en stopsequenties van belang.

Meten is weten, meer meten is meer weten. Een grotere sample space is welkom!

[TEAMIKKE]

Ik heb de APA3-1500R. Ik weet niet of die van het nieuwe protocol gebruik maakt? De post boven je gebruik ik voor het aansturen met het 32 bits protocol en dat werkt prima. Ik weet niet of 'het nieuwe protocol' nog weer anders is dan de 32 bits versie.

Dit is het signaal dat mijn zender uitzendt als ik kanaal 2 aanzet. Dit voldoet aan de specificaties in de post hierboven en aan het topic op CO waar je naar refereert. De timing is niet af te lezen maar die was inderdaad 260us bij mij.

[Fuzzillogic]

Ja, alle kaku's met een typenummer dat begint met 'A' zijn uit de nieuwe serie. Het protocol uit CO klopt, voor zover ik kan nagaan. Het verschil zit em in de timings. Op zich komen die ook niet zo nauw allemaal, maar voor bereik en compatibiliteit kan het toch net het verschil maken.

[NIB0R]

Fuzzillogic schreef op donderdag 22 maart 2012 @ 15:15:
Is hier iemand met een scope en een nieuwe kaku-zender die even wat getallen kan bevestigen? Ik heb een sample-space van precies 1 zender en 0 ontvangers. Dat is vrij beperkt. Met een oscilloscoop heb ik de meeste getallen uit deze CO-post grotendeels kunnen verifiëren, met toch enkele verschillen:

1. De periodetijd (1T) is bij mij ~260us. Is dat altijd zo bij kaku? Zijn er klonen met afwijkende timing?
2. Een '0'-bit is T, T, T, 5T, dus totaal 8T
3. Een '1'-bit is T, 5T, T, T, hier dus ook 8T totaal.
4. De start-sequence is bij mij 1T hoog, 10,44T laag. (totaal 2,96ms gemeten) CO meldt hier 1T hoog, 9T laag. Waarom dit geen mooi rond getal wordt is mij een raadsel
5. De stop-sequence is bij mij 1T hoog, 40T laag. (totaal 10,60ms gemeten) CO meldt alleen 1T hoog "lang laag".
6. 'dim' kan ik niet meten, bij gebrek aan hardware.

Deze timings zijn van belang omdat ik bezig ben met een new-kaku-receiver voor in de library (ja echt!). Mocht de periodetijd bij al deze apparaten ~260us zijn dan hoeft er geen periodetijd-detectie te komen en is herkenning betrouwbaarder. Mocht de periodetijd wél variëren, dan moet deze dus bepaald worden, en dan zijn m.n. de start- en stopsequenties van belang.

Meten is weten, meer meten is meer weten. Een grotere sample space is welkom!

Ik kan morgen de AMST-606 (deur magneet schakelaar) voor je testen op me werk.

Tof dat je bezig bent met new kaku in de library

[Fuzzillogic]

NIB0R schreef op donderdag 22 maart 2012 @ 21:42:
[...]
Ik kan morgen de AMST-606 (deur magneet schakelaar) voor je testen op me m'n werk.

Dat zou mooi zijn, maar dat is precies het ding dat ik ook heb. Dus of we daar veel mee opschieten betwijfel ik

[Fuzzillogic]

Code voor het ontvangen van de nieuwe KAKU serie staat nu in de dev-branch. Download. Gebruik ervan lijkt veel op die voor de oude, maar vanwege de verschillen is het toch een aparte decoder geworden. Ik heb een example toegevoegd, ShowReceivedCodeNewKaku, die het e.e.a. duidelijk maakt.

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!

M.b.v. InterruptChain is het mogelijk om zowel de oude als nieuwe gelijktijdig te ontvangen. Dit heb ik echter nog helemaal niet getest Mogelijk probleem hierbij is het beperkte RAM-geheugen van de 168. Ik kan nog proberen dat wat te optimaliseren...

Als je test, kun je me dan de "period" doorgeven die ShowReceivedCodeNewKaku geeft?

Code voor verzenden ontbreekt nog, maar die is relatief eenvoudig, en werkende voorbeelden staan hierboven ook al.

[NIB0R]

Fuzzillogic schreef op donderdag 22 maart 2012 @ 22:34:
[...]

Dat zou mooi zijn, maar dat is precies het ding dat ik ook heb. Dus of we daar veel mee opschieten betwijfel ik

Screenshots zijn mislukt. Er zat helemaal geen timing bij ofzoiets. Puur de pulsjes. Haha daar kan je niets mee.
Ik zal kijken of het van de week beter lukt.

[Fuzzillogic]

Hmmfr. Het bereik is ondanks short-pulse-filter nog niet echt denderend. Dus met de scope de output van de ontvanger eens bekeken: screenshot Groen/onder de RSSI-output, oftewel de "analoge" uitvoer. Geel/boven de digitale uitvoer. De digitale uitvoer hangt normaal gesproken dus aan de Arduino.

Het probleem is duidelijk: er zit nog een blokgolfje in de lucht. Hoewel significant minder dan het signaal van de zender zelf struikelt de ontvanger er duidelijk over: het kleine golfje in het analoge wordt een brede puls in het digitale. Sja, dat is funest voor de decoder. En daar valt ook niet tegenop te filteren met software.

De vraag is: hoe te fixen? Andere ontvanger die gemaakt is voor meer/minder baud? Of toch de analoge uitgang gebruiken, icm een tor? Ik ga dat laatste morgen eens proberen. Een opamp zou hier geschikter voor zijn, maar die heb ik niet in huis.

Anyway, als je problemen hebt met bereik, dan hoeft dat niet direct aan de code te liggen.

[ Voor 5% gewijzigd door Fuzzillogic op 24-03-2012 22:39 ]

[memphis]

RSSI is niet het analoge output signaal maar een ontvangst sterkte signaal.Zeker weten dat je het juiste benoemt of de juiste pin gebruikt? In mijn projectje komt aan de RSSI uitgang een ledbar met een LM3914 IC.

Maar om analoog naar digitaal te krijgen heb je een zgn data slicer nodig. Als je er op googled met afbeeldingen kom je de nodige schema's tegen maar alle met opamps. Ben zelf ook bezig geweest met een goedkoop setje maar daar kwam uit het analoge nog de nodige troep mee en de uitgang was hoog-ohmig dus was een opamp of een cmos schmitt trigger zoals een 4093 noodzakelijk.

Een data slicer bestaat uit niets anders dan een comperator en een laagdoorlaat filter.

De betere data slicer is wat ingewikkelder maar ook bestelbaar
http://www.radiometrix.com/files/additional/qr96.pdf

[Fuzzillogic]

memphis schreef op zaterdag 24 maart 2012 @ 23:20:
RSSI is niet het analoge output signaal maar een ontvangst sterkte signaal.Zeker weten dat je het juiste benoemt of de juiste pin gebruikt? In mijn projectje komt aan de RSSI uitgang een ledbar met een LM3914 IC.

Bij de pin staat RSSI. En sja, dat klopt, alleen zou je idd verwachten dat er een laagdoorlaatfilter op zit.

Maar om analoog naar digitaal te krijgen heb je een zgn data slicer nodig. Als je er op googled met afbeeldingen kom je de nodige schema's tegen maar alle met opamps.

Slicers zijn voor frequency shift keying wat ik zo lees, maar dit protocol is simpel on/off keying

Het idee is om zoveel mogelijk in software te doen. Probleem is dat de ontvanger niet perse gemaakt is voor deze transmitters. Tot dusver ging het goed, maar met dit signaal geeft het problemen. Misschien is het ook gewoon de zender, het dingetje draait op 3V terwijl de andere zenders op 12V werken.

Morgen verder.

[memphis]

Die Radiometrix dingen draaien intern ook op 2.8 volt en daarmee worden in de open lucht op 10mW zendvermogen vele kilometers gehaald, een bijkomstigheid is wel dat ze aan de ontvangerkant flinke antennes en speciale ontvangers gebruiken. De NTX2 zender is erg populair bij de gasten die van die balonnen in de atmosfeer brengen en gebruiken de 433mhz set voor het doorsturen van de GPS informatie op een lage baudrate (50 - 300 baud). Het geheim van deze zender is dat die smalbandig met een FM modulatie werkt waarmee het bereik stukken betrouwbaarder wordt tov. die goedkope breedbandige AM setjes waarmee ik tot op heden alleen maar slechte ervaringen heb. Het grappige is dat de centrale vergrendeling van mijn Renault ook op die frequentie zit en ook met gemak 100 meter op de parkeerplaats haalt

Belangrijk voor het bereik is ook de antenne. Ik zelf begin met een standaard draadje van 17cm maar als het bereik nog niet goed is zal ik over gaan naar een GP antenne of een di-pool. Bij de Conrad hebben ze mooie GP antennes voor de 433mhz
Hier een handig document over 433mhz antennes. http://www.rfm.com/corp/appdata/antenna.pdf

Even een testopstelling waar ik mee bezig ben:



De dingen die gemeten gaan worden:
- motortemp
- luchttemp
- brandstof temp
- luchtvochtigheid
- 3 assig G-krachten (acceleratie, bochtsnelheid en op de Z-as de rust in het chassis)
- toerental
- snelheid
- luchtvochtigheid

[Fuzzillogic]

Oeps De interferentie waar ik last van had veroorzaakte ik zelf. Lui als ik ben had ik probes van de scope niet netjes geground, want sja "toch common ground via USB". Dat laatste klopt wel, maar dat geeft toch blijkbaar allerlei rommel op allerlei signalen...

Enfin, het hele gedoe met transistor (wat qua concept wel werkte) is overbodig. De software werkt gewoon prima. De nieuwe kaku-signalen zijn een stuk langer dan de oude. Daar waar het bij de oude nog wel handig was om te wachten tot bijv. 3x dezelfde code was ontvangen alvorens er iets mee te doen, is het bij new kaku eigenlijk niet nodig. In de example heb ik nu ingesteld dan 2x dezelfde code ontvangen moet worden als voorbeeld, maar voor meeste toepassingen kan dat ook prima 1 worden.

Ook heb ik het filter voor te korte piekjes verbeterd. Ik denk dat dat filter goed werk doet, en zal het ook gaan toepassen op de code van de andere ontvangers. Nadeel is wel dat het weer een paar byte extra RAM kost

Aanpassingen staan in de repository. Iemand hier met een Home Easy die het eens kan testen?

@memphis, mooi document over antenne. Ik gebruik nu een simpele spriet van ~16cm, seems to work fine. Maar goed om te weten dat het ook wat compacter kan

[sPENKMAN]

@ Fuzzillogic
Wil je erg bedanken voor de moeite welke je hierin hebt gestoken. De Elro functionaliteit (aan/uit) schakelen werkt perfect met mijn Arduino Uno v3. Ik zag dat je deze nog niet had kunnen testen tot op heden. Ook het switchen van kanalen gaat prima (zit zelf op 31 atm).

Mocht je nog iets getest moeten hebben; ik heb dus een setje liggen.

[Fuzzillogic]

Mooi Heb je, of iemand anders, toevallig ook een remote uit de kaku A-serie, of van HomeEasy? De dev-branch heeft support voor ontvangen van deze, maar ik bij gebrek aan hardware kan ik niet alles testen. Zo weet ik niet welke "unit" verstuurd wordt als je group on/off stuurt. Met de nieuw toegevoegde example in de dev-branch kun je dat zien.

Overigens heeft die dev-branch nu ook support voor verzenden van kaku A-serie, maar ik heb nog geen tijd gehad om die te testen - ik weet niet eens of het überhaupt te compileren is Maar het gaat er dus wel komen!

[sPENKMAN]

Ik heb enkel een setje van Elro liggen, misschien dat mijn pa een ander merkt heeft, zal het even navragen.

[Verwijderd]

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.

[Verwijderd]

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/

[Verwijderd]

-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?