433MHz-communicatie met microcontrollers

[Fuzzillogic]

sunoke schreef op woensdag 18 juni 2008 @ 20:58:
@Atlas: Die 433MHz is geen directe vervanger voor een draadje, dwz. je krijgt behoorlijk wat rotzooi binnen. Die zul je op een of andere manier moeten kunnen identificeren (of omgekeerd, de data identificeren). Vaak wordt de data hiervoor geencodeerd. Zoek bijvoorbeeld eens naar manchester codering.

Mwa, moet wel goedgaan. Vanaf µU naar zichzelf luktte het ook, zij het met wat rommel erdoor. Mogelijk dat de PC moeite heeft om op het signaal te syncen, omdat je van een situatie van ruis direct overgaat naar een situatie met gewenst signaal. Een oplossing kan dan ook wel eens zijn om voor het echte signaal even wat pulsjes te sturen om de ontvanger a.h.w. in te stellen op het juist ontvangniveau. Als je een scope hebt, dan is het handig om daar eens mee te kijken wat je zoal binnenkrijgt.

---

Gisteren heb ik bij de blokker een remote switch set gekocht. Ik had em nog niet eens getest of hij lag al uit elkaar om te zien welke chip het ding gebruikt Het is de bekende 2262, zelfde principe dus als de (oude) kaku en Action. Binnenkort eens de Arduino-library uitbreiden met een class voor de blokker-set. Should be really easy

Ook maar eens verdergaan met de rest van het gebeuren, heb nu weer wat tijd. @Shorty24, bedankt voor je code Maar ik heb het idee dat er wat ontbreekt? (as in: code voor timing van pulsen enzo) Het concept om de code on-the-fly te decoderen is wel geinig, de vraag is wel of je er genoeg tijd voor hebt tussen de pulsen..

[Atlas]

Ha we zijn een stapje verder, mijn ontvanger had een zwevende aarde ( ). Dus die kreeg weinig door. Maar nu ik 5x "Hello World!" vanaf mijn Atmel de 433 Mhz draadloze band inknal krijg ik keurig netjes 4x "Hello World!" terug op mijn compoort van mijn PC. Tot zover deel 1
Nu eens kijken of ik het met de ontvangende Atmel kan opvangen. Ik vrees dat ik van CodeVision af moet stappen en het zelf compleet van scratch mag gaan coden, want ik heb het idee dat CodeVision iets raars doet hiermee...

[GuruMadMat]

Hey mensen,

Ik zit met deze doelstelling:

Ik wil wat domotica in mijn huis, en omdat ik (in een ander project) toch een aantal linux servers zal hebben,
dacht ik er aan om via mijn pc de lichten, schakelaars, weer station... te besturen.

Het balangrijkste zijn de lichten, ik dacht om te werken met RF signalen maar heb geen idee hoe ik dit best doe..

Er zullen 10 schakelaars moeten vervangen worden door RF schakelaars...
De schakelaar moet nog altijd manueel te bedienen zijn.
De schakelaar moet kunnen zeggen in welke stand hij nu is.
Alles moet apart te besturen zijn.
En de gehele opzet moet makkelijk uitbreidbaar zijn om schakelaars te besturen,
alsook bvb dit of een ander weerstation uit te lezen...

Ik heb ook al dit gevonden, mss kan ik dit gebruiken om de schakelaars om te bouwen...

Nu ik moet zeggen dat ik niets ken van elektronica maar dit vraag ik wel aan iemand.
Tips over de software(linux ofcourse) zijn ook altijd welkom...

Hoe zouden jullie dit realiseren?

Matthew

[j-a-s-p-e-r]

GuruMadMat schreef op vrijdag 20 juni 2008 @ 01:55:
Hey mensen,

Ik zit met deze doelstelling:

Ik wil wat domotica in mijn huis, en omdat ik (in een ander project) toch een aantal linux servers zal hebben,
dacht ik er aan om via mijn pc de lichten, schakelaars, weer station... te besturen.

Het balangrijkste zijn de lichten, ik dacht om te werken met RF signalen maar heb geen idee hoe ik dit best doe..

Er zullen 10 schakelaars moeten vervangen worden door RF schakelaars...
De schakelaar moet nog altijd manueel te bedienen zijn.
De schakelaar moet kunnen zeggen in welke stand hij nu is.
Alles moet apart te besturen zijn.
En de gehele opzet moet makkelijk uitbreidbaar zijn om schakelaars te besturen,
alsook bvb dit of een ander weerstation uit te lezen...

Ik heb ook al dit gevonden, mss kan ik dit gebruiken om de schakelaars om te bouwen...

Nu ik moet zeggen dat ik niets ken van elektronica maar dit vraag ik wel aan iemand.
Tips over de software(linux ofcourse) zijn ook altijd welkom...

Hoe zouden jullie dit realiseren?

Matthew

Hoi Matthew,

Heb je hier al gekeken? [howto] Klik-aan-klik-uit aan computer
Daar gaat het wat meer over communicatie tussen klikaanklikuit spul en de computer, ik denk dat dat wat meer in je straatje ligt. Als je terugkoppeling wilt zal je trouwens naar X10 (of Z-Wave ?) moeten kijken. Dat is alleen wel vrij duur spul.
Ik gebruik zelf goedkoop KaKu spul van diverse merken icm. een afstandsbediening voor handmatig gebruik. Het nadeel hiervan is dat er geen terugkoppeling naar de centrale sturing is, dus dat deze sturing nooit weet of een licht/verbruiker aan of uit staat. Helaas. Wat wel kan is alle signalen opvangen en o.b.v. de signalen bekijken of iets aan/uit staat.
Kortom: leuk project dus. Er is gelukkig een boel over te vinden (ook hier op got/tweakers).

[GuruMadMat]

j-a-s-p-e-r schreef op vrijdag 20 juni 2008 @ 02:12:
[...]


Hoi Matthew,

Heb je hier al gekeken? [howto] Klik-aan-klik-uit aan computer
Daar gaat het wat meer over communicatie tussen klikaanklikuit spul en de computer, ik denk dat dat wat meer in je straatje ligt. Als je terugkoppeling wilt zal je trouwens naar X10 (of Z-Wave ?) moeten kijken. Dat is alleen wel vrij duur spul.
Ik gebruik zelf goedkoop KaKu spul van diverse merken icm. een afstandsbediening voor handmatig gebruik. Het nadeel hiervan is dat er geen terugkoppeling naar de centrale sturing is, dus dat deze sturing nooit weet of een licht/verbruiker aan of uit staat. Helaas. Wat wel kan is alle signalen opvangen en o.b.v. de signalen bekijken of iets aan/uit staat.
Kortom: leuk project dus. Er is gelukkig een boel over te vinden (ook hier op got/tweakers).

Hey jasper,
Ik had daar al gekeken en nu heb ik wat meer info over X10 gezocht.

Ik denk dat het met X10 wat duur zou uitkomen.
Kan ik dit door een kennis die elektronica volgt laten inbouwen in een schakelaar en zo via een relais de schakelaar aanpassen? Is dit haalbaar of is dit te kostelijk? rekening houden dat werkuren wel in Duvel ofzo zal betaald worden

[j-a-s-p-e-r]

Ehm. Het is een 433 mhz ontvanger. Daar kan je verschillende signalen over sturen (bijv rs232) of een KaKu signaal. Hoe je daar direct een relay mee aan wilt sturen is mij niet helemaal duidelijk.

Je kan wel een microcontroller eraan hangen die het signaal decodeerd en daar vervolgens wat mee doet (aanstuurt dus). Kijk ook eens bij de afgelopen actie op samenkopen.net

Maar als ik jouw verhaal zo lees ben jij niet gewoon op zoek naar een simpel klikaan/uit setje (à 19 euro bij de gamma) om dingen op afstand aan of uit te zetten? Dat is al kant en klaar, eventueel in te bouwen (ontvanger/schakelaar uit elkaar halen) en veel simpeler en goedkoper.

[Fuzzillogic]

Zoals gezegd heb ik deze week een Blokker-set gekocht. Inmiddels heb ik de Arduino Remote Switch Library bijgewerkt naar v1.2, met support voor de Blokker-remotes! Ondersteund worden nu dus de KlikAanKlikUit, de Action set en de Blokker set. (vergeet bij installatie de .o object file niet te wissen van de oude library; deze wordt anders niet opnieuw gecompileerd)

Hoewel ze allemaal dezelfde basis hebben, gebruiken ze toch net andere timings en coderingen. Maar mocht je een remote hebben die lijkt op een van deze units, dan is de kans aanwezig dat het lijkt. Let vooral op aantal knoppen/schakelaars:

Action:


Blokker:


En natuurlijk KaKu:


De KaKu decoder is niet bijgewerkt, deze is flexibel genoeg om een groot aantal van dit soort apparaten te decoderen/kwantificeren, w.o. dus de blokker-remote.

De codes van deze apparaten zijn verschillend, er is geen clash tussen de getallen, m.a.w. de getallen uit de decoder zijn uniek voor elke knop/setting van elk van de drie bovenstaande remotes.

[ Voor 0% gewijzigd door Fuzzillogic op 21-06-2008 00:50 . Reden: Nu met goede link ;) ]

[Shorty24]

Hi allemaal!

@FuzziLogic:. Je hebt gelijk.. Er mist nog van alles voor het verzenden.

Het decoderen gaat vooralsnog wel goed. Ook lijkt de Arduino vooralsnog snel genoeg om de diverse protocollen te filteren uit een signaal.
Ik bemerk wel dat wanneer de signalen heel snel gaan, mijn code/de Arduino niet snel genoeg meer is. Hier kwam ik achter bij het verzenden van signalen. Als dat heel snel gaat, dan krijg ik hele onregelmatige ontvangst-timings.

[Shorty24]

Beste Arduino-hobbyers,
ik probeer zieltjes te winnen om mee te doen aan m'n Home Automation/Domotica project op basis van de Arduino en RF. Ik heb de source code ondergebracht bij code@Google, zodat iedereen het kan gebruiken+verbeteren.

Ik ben goed op weg met het implementeren van de verschillende protocollen. Op dit moment heb ik m'n huis al aardig aan het volhangen met RF-spul. Zo heb ik RF-rookmelders, RF-bewegingsmelders, RF-lichtdimmers, RF-buitenlamp, RF-weerstations. Vrijwel al deze signalen worden al ontvangen door m'n Ardduino met m'n sketch.

http://code.google.com/p/arduinoha/

gr. Sander

[Phalox]

Past dat nog allemaal in de arduino ? zijn geheugen is beperkt, zeker wanneer je de taal gaat gebruiken die erbij zit. (alle overbodige zaken worden ook mee gecompiled)
Ik denk dat je moet zorgen dat na verloop van tijd de IC uit de arduino gehaald wordt, en deze gebruikt wordt zonder het bordje.. ik vind het nogal verspilling van de interface wanneer deze in de kast ligt stof te happen. Maar nu is het waarschijnlijk eenvoudiger om het zo te doen...

Succes ermee!

[Megamind]

Leuk project inderdaad, maar die Arduino staat mij ook niet zo aan, leuk speelgoed daar niet van, maar wel duur in gebruik. Is het niet leuker om een helemaal standalone te maken, die 433 modules + een 16Fx zijn niet zo duur...

[Fuzzillogic]

Megamind schreef op maandag 07 juli 2008 @ 12:22:
Leuk project inderdaad, maar die Arduino staat mij ook niet zo aan, leuk speelgoed daar niet van, maar wel duur in gebruik. Is het niet leuker om een helemaal standalone te maken, die 433 modules + een 16Fx zijn niet zo duur...

"Arduino" is niet meer dan een ATMega168 met een bootloader. Als je een programmer hebt dan kun je de bootloader zelf erin gooien. Dus de kosten bestaan dan ook in feite slechts uit een ATMega168, voor een paar euro.

Er zijn ook goedkopere maar compatible alternatieven: boarduino en freeduino. En er is een how-to hoe je een 'arduino' namaakt op een breadboardje.

[Shorty24]

Hi all,

@Tokes: Je hebt helemaal gelijk. Ik ben tegen de 16kb geheugenlimiet van de Arduino aangelopen. Hoewel ik nog een een paar kb eraf heb kunnen halen, door compactere code te schrijven. Hield het uiteindelijk op, terwijl ik nog veel meer code voor de Arduino wilde gaan schrijven.
Ik heb het hierom over een andere boeg gegooid. Ik heb nu zelf een softwarematige self-clocking Manchester-code decoder geschreven. Op internet heb ik namelijk nog nergens de sourcecode van een Manchester-code decoder kunnen vinden. Met m'n code kan ik vrijwel alle RF-signalen herkennen en omvormen tot een bitstream. Het decoderen van de bitstream is uiteraard wel nog per fabrikant verschillend. Ik wil m'n decoder nu alleen nog uitbreiden zodat hij langere bitstreams kan ontvangen. M'n autosleutel geeft bijvoorbeeld een bitstream van 350 pulsen af (* 2 bytes (16-bits), weer geheugen te weinig). Maar ik denk nog wel de logica te kunnen uitbreiden, dat tijdens het ontvangen er overgeschakeld kan worden naar on-the-fly opbouwen van de bitstream, nu wordt pas aan het eind van de pulse-signalen de bitstream opgebouwd over de gehele code.
Wanneer ik verder ben met m'n code, ga ik het weer uploaden.
greetz, Sander

[j-a-s-p-e-r]

Hm. Dat gaat mij nu toch echt boven de pet. Zeer netjes Sander!
Ik ben inmiddels flink met de arduino aan het spelen, erg leuk spul allemaal. Ondertussen ben ik weer aan het sleutelen aan een backend om alles op tijd, en via internet etc, aan te sturen. Waarschijnlijk ga ik over op java vanwege de (bijna) platform afhankelijkheid, maar dan moet ik eerst wat beter java kunnen.

Maar ik ben erg benieuwd wat je er uit krijgt, hou ons gerust op de hoogte

[Fuzzillogic]

j-a-s-p-e-r schreef op dinsdag 15 juli 2008 @ 20:28:Waarschijnlijk ga ik over op java vanwege de (bijna) platform afhankelijkheid, maar dan moet ik eerst wat beter java kunnen.

Ben ook bezig om in Java met het ding te kletsen, maar tot mijn grote verbazing ondersteunt java geen COM-poorten. Je zult hiervoor externe libraries moeten gebruiken, waarvan een gedeelte zelfs platform-specifiek is Er is wel een open source, cross platform implemenatie, rxtx. De Arduino-software gebruikte deze lib ook.

[Verwijderd]

ik heb zojuist ook een Arduino Diecimila besteld in Amerika.
Kan niet wachten tot ik hem binnen heb. Nu nog een goede 433Mhz zender en ontvanger die hierop aabgesloten kunnen worden en ik ben zeer tevreden. Hoe zit dat nu eigenlijk met dat touth screen LCD, kan dat hierop aangesloten worden? en hoe mooilijk, makkelijk is het om dat te gebruiken voor aansturing van bv. kleppen met timerprogramma's ed. Ik ben zelf programmeur van oa. Peoplesoft, en asp c++ ed. Dus het programmeren moet wel lukken.

[Fuzzillogic]

Verwijderd schreef op zaterdag 19 juli 2008 @ 15:40:
ik heb zojuist ook een Arduino Diecimila besteld in Amerika.

Waarom Amerika? Ok dollarkoers enzo, maar ook BTW en invoerheffing... Arduino wordt gemaakt in Italie, en je kunt het dus net zo goed direct daar bestellen. Geen gezeik met BTW en invoerheffingen. Hier in Nederland kan ook, maar ze EZTronics gooit er doodleuk €10 aan extra kosten bovenop Het wordt dan wel aangetekend verstuurd.

Kan niet wachten tot ik hem binnen heb. Nu nog een goede 433Mhz zender en ontvanger die hierop aabgesloten kunnen worden en ik ben zeer tevreden. Hoe zit dat nu eigenlijk met dat touth screen LCD, kan dat hierop aangesloten worden? en hoe mooilijk, makkelijk is het om dat te gebruiken voor aansturing van bv. kleppen met timerprogramma's ed. Ik ben zelf programmeur van oa. Peoplesoft, en asp c++ ed. Dus het programmeren moet wel lukken.

Je kunt er zo ongeveer alles op aansluiten, mits je wat elektrotechnische knowhow hebt, en niet vies bent van low-level bitsmijten. Er is bij mijn weten geen libraries voor touch sceen LCD's specifiek voor Arduino. Wellicht handiger om te starten met een standaard HD44780 LCDtje. Daar zijn wel libs voor (zelfs in de standaard distro) en je kunt er zelf ook nog makkelijk tegenaan kletsen.

[j-a-s-p-e-r]

De invoerrechten vanuit de USA op zo'n lage bestelling zijn er niet, of ze zijn nihil. Al moet ik zeggen dat bestellen uit hongkong altijd mijn voorkeur heeft, ik heb mijn freeduino uit USA en moest er toen bijna 5 weken op wachten maar de arduino uit hongkong (kant en klaar met shipping voor 23 euro) was er binnen 10 dagen.

Die touchscreen kan je, denk ik, aansturen als een redelijk generiek grafisch lcd. Daar is vast wel een library voor op de arduino. Het 'touch' gedeelte is met een paar weerstanden en een analoge AD ingang prima te doen.

@Fuzzilogic;
Ik ben nu met jouw (oude) code bezig met de processing. Eens kijken wat ook X10 zoals de lucht in gooit, er interessant. Helaas zit ik bij m'n ouders waar ik bijna geen electrozooi heb dus het meeste blijft een beetje beperkt tot proberen. Hoe gaat het met jouw VW omgeving? Ik ben erg benieuwd!

Ik ben zelf een beetje aan een systeem aan het denken waarbij de arduino een signaal kan 'leren' op basis van herkenning ipv decodering. Dat moet dat door worden gestuurd naar de computer onder een normale 'naam' zodat de automatiseringssoftware het weer op kan pakken.
Het valt me trouwens tegen van java dat het niet standaard een compoort ondersteund! Beetje jammer. Moet nog eens kijken of er dan nog een beter alternatief is qua multiplatformheid.

[Tasma]

hoe eenvoudig moeilijk is het om een bestaand 433mhz signaal op te vangen, en te klonen? om zo een afstandbediening in te lezen voor later gebruik?

[ Voor 5% gewijzigd door Tasma op 19-07-2008 22:58 ]

[Fuzzillogic]

j-a-s-p-e-r schreef op zaterdag 19 juli 2008 @ 20:08:
De invoerrechten vanuit de USA op zo'n lage bestelling zijn er niet, of ze zijn nihil. Al moet ik zeggen dat bestellen uit hongkong altijd mijn voorkeur heeft, ik heb mijn freeduino uit USA en moest er toen bijna 5 weken op wachten maar de arduino uit hongkong (kant en klaar met shipping voor 23 euro) was er binnen 10 dagen.

De grens ligt op iets van €32 incl verzendkosten dacht ik. Vanaf december wordt het €150 oid. En meestal ben ik ongeduldig en lap ik liever paar euro meer om het snel te hebben

@Fuzzilogic;
Ik ben nu met jouw (oude) code bezig met de processing. Eens kijken wat ook X10 zoals de lucht in gooit, er interessant. Helaas zit ik bij m'n ouders waar ik bijna geen electrozooi heb dus het meeste blijft een beetje beperkt tot proberen. Hoe gaat het met jouw VW omgeving? Ik ben erg benieuwd!

Is wireless X10 gestandaardiseerd? En eigenlijk zou een 2-way protocol fijner zijn, zodat je ook kunt controleren of de lamp ook echt uit is. A10 bijv. Maar ik heb geen idee hoe open/prijzig/lastig dat dat allemaal is...

De Virtual Machine bevatte ontzettend veel bugs, zo bleek Java debuggen is makkelijker, maar debuggen op de Arduino valt tegen; even door je code 'steppen' kan wel dacht ik, maar vereist toch ook weer hardware en software die ik niet heb. Trial and error dus vooral, maar inmiddels kan de VM ook aardig wat debug-info over de COM-poort versturen.

Maar het lijkt nu allemaal best goed te werken. Momenteel dus aan het prutsen met de RS232-communicatie vanuit Java, zodat je het ding vanuit een Java-omgeving kunt programmeren. Daar boek ik wat vooruitgang mee. The hard part is het maken van een GUI rondom de compiler vrees ik. En eigenlijk wil ik nog een simulator maken, zodat je je code kunt simuleren in een GUI op je desktop alvorens te uploaden naar de arduino.

Overigens zit er nog geen specifieke support voor 433MHz-spul in. Mijn idee is om een generiek systeem te maken, dat makkelijk uit te breiden is met extra functies. Daarvoor is er een EXTERNAL opcode, waarmee je gewoon normale C-functies kunt aanroepen die gewoon in flashrom staan.

Klinkt complex, maar is het uiteindelijk niet. Hoop ik

Ik ben zelf een beetje aan een systeem aan het denken waarbij de arduino een signaal kan 'leren' op basis van herkenning ipv decodering. Dat moet dat door worden gestuurd naar de computer onder een normale 'naam' zodat de automatiseringssoftware het weer op kan pakken.

Klinkt als wat Shorty aan het doen is met zijn ArduinoHA-project.

Het valt me trouwens tegen van java dat het niet standaard een compoort ondersteund! Beetje jammer. Moet nog eens kijken of er dan nog een beter alternatief is qua multiplatformheid.

Erg jammer ja. Maar RXTX doet het wel. Er is ook een JD2XX-project, waarmee je de FTDI-chipjes directer kunt aansturen. Werkt onder Windows en Linux, maar helaas geen MacOS, iets dat RXTX wel doet.

Tasma schreef op zaterdag 19 juli 2008 @ 22:53:
hoe eenvoudig moeilijk is het om een bestaand 433mhz signaal op te vangen, en te klonen? om zo een afstandbediening in te lezen voor later gebruik?

Niet moeilijk. In feite meet je gewoon de lengte van de eentjes en nulletjes. Iets wat mijn code om een KaKu-signaal te decoderen (zie eerder in deze thread) ook al doet. Het ontvangen signaal opnieuw uitzenden is dan een heel koud kunstje met Arduino.

Het grootste probleem is echter het beperkte geheugen. De nieuwe KaKu remotes gebruiken een veel langer signaal dan de oude. Ik denk dat je 1, hooguit 2 verschillende signalen in het RAM-geheugen kunt opslaan. Je zou ze nog in FLASH kunnen opslaan, maar dat wordt aanzienlijk lastiger...

Vanavond kwam ik nog langs deze real time clock en memory/datalogger. Een RTC zal voor mijn uiteindelijke doel (stand-alone home automation) een must zijn. De datalogger-module biedt echter ook interessante features: je zou er dus je ontvangen signalen in op kunnen slaan, maar m'n VM zou het zelfs ook kunnen gebruiken als programmageheugen

[Verwijderd]

Meer gegevens van winkel in amerika, ebay shop:

Arduino Diecimila board fully assembled
Web address: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=380047874162
Item number: 380047874162
Seller User ID: nkc_store

Your total is:
$34.50 per item
$0.00 insurance (not offered)
$0.00 Sales discounts (-) or charges (+)
$4.00 shipping/handling

-----
$38.50 = Total


is dus 24.34 euro in totaal

[j-a-s-p-e-r]

Ja, alleen is dat dus wel uit USA (NKC_store) en die waren bij mij sloooooom. Ik heb later bij een andere vent (bijv ebay #130239842731 ). Die was er binnen 10 dagen inclusief alles. Misschien wel een aanrader dus.

[HammerT]

Hoe voorkomen jullie het synchroneren probleem? Ik ontvang namelijk constant troep op me ontvanger waardoor er maar eens in de zoveel tijd goed data wordt ontvangen.

Hoewel het ook wat anders kan zijn, aangezien wanneer ik een string van enkele karakters verstuur deze helemaal nooit aan komt.

Ik gebruik de "ENHANCED UNIVERSAL SYNCHRONOUS ASYNCHRONOUS RECEIVER TRANSMITTER" van me PIC btw ^^

[Atlas]

Gewoon die string een keer of 4-5 oversturen, de 1e zal wegvallen, maar de rest komt wel aan en dan kun je daar op triggeren

[j-a-s-p-e-r]

Kennen jullie xPL ?
Ik heb het gister 'ontdekt' en ben sindsdien aan het inlezen. Even een zeer korte beschrijving:

What is xPL?
xPL is an open protocol intended to permit the control and monitoring of home automation devices. The primary design goal of xPL is to provide a rich set of features and functionality, whilst maintaining an elegant, uncomplicated message structure. The protocol includes complete discovery and auto-configuration capabilities which support a fully "plug-n-play" architecture - essential to ensure a good end-user experience.

xPL benefits from a strongly-specified message structure, required to ensure that xPL-enabled devices from different vendors are able to communicate without the risk of incompatibilities.

Het mooie is dat het ook nog eens over alle TCP/UDP devices (java, linux, windows, etc) kan in het netwerk (hier moet dan de xPLHub op staan) en daar kan weer een 'gateway' aan. Op dit moment bestaat bijvoorbeeld de cm11 en de RFXCOM gateway als xPL applicatie. Dit schept wel mogelijkeheden.

Waar ik nu aan zit te denken is om met de arduino een rfxcom ontvanger na te doen zodat hiervoor dezelfde plugin kan worden gebruikt. Evt zou je dan ook homeseer kunnen gebruiken (maar die vind ik zelf zwaar overpriced). De RFXCom is zelf trouwens ook vrij duur (afhankelijk van de opties > €200)
Wat denken jullie van het framework en het idee ernaast?

[ Voor 3% gewijzigd door j-a-s-p-e-r op 24-07-2008 12:18 . Reden: Linkjes ingevoegd voor u gemak ;) ]

[Shorty24]

@HammerT: Wat mij opviel is dat de ruis die m'n RF-shield ontving ongeveer overeen kwam met het lezen/schrijven van m'n notebook-hardeschijf. Dit gebeurde wanneer ik m'n Arduino voedde via de USB.
Nadat ik de Arduino via een externe 12volt voeding had aangesloten, had ik VEEEEEEEL minder ruis.

[j-a-s-p-e-r]

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

[Joozt]

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

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

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

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

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

[franssie]

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

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

[j-a-s-p-e-r]

Ah leuk dat er nog meer mee bezig zijn!

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

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

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

code:

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

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

code:

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

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

code:

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

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

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

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

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

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

[Joozt]

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

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


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

[franssie]

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

<snip>

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

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

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

[ Voor 51% gewijzigd door franssie op 30-07-2008 14:42 ]

[j-a-s-p-e-r]

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

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


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

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

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

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

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


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


[...]

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

Dankje, leuk om te horen

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

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

code:

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

unsigned long IntervalTimer_1;
int status=HIGH;

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

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

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

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


void loop(){

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

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

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

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

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


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

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

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

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

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

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

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

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

  } // if
 
 
} //Loop

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Joozt]

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

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

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

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

[ Voor 11% gewijzigd door Joozt op 05-08-2008 10:32 ]

[stavast]

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

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

kan iemand mij daarmee helpen?

[Fuzzillogic]

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

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

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

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

[stavast]

bedankt voor je hulp mijn zender komt van samenkopen.net

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

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

[ Voor 74% gewijzigd door stavast op 03-09-2008 18:47 ]

[Fuzzillogic]

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

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

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

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

[stavast]

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

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

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

[Shorty24]

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

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

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

Heeft iemand hier een idee over?

gr. Sander

[j-a-s-p-e-r]

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

Dus dood is het nog niet:p

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

[Tortax]

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

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

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

Grtz

[ Voor 3% gewijzigd door Tortax op 28-09-2008 19:12 ]

[Fuzzillogic]

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

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

[Parasietje]

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

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

[Joozt]

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


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

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

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

[Demo]

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

[ Voor 4% gewijzigd door Demo op 02-10-2008 00:48 ]

[Megamind]

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

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

[Demo]

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

[Verwijderd]

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

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

[Megamind]

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

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

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

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

[Joozt]

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

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

[Megamind]

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

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

[LED-Maniak]

Goed, Ik heb dus ook een kaku achtig signaal


Heb alleen geen timers meer over om puls lengte te tellen en ondertussen moet het programma wel door blijven gaan met werken. Heeft iemand enig idee hoe ik dit varkentje kan wassen zodat het werkt in mij AVR?

Ik heb zoiezo al een timer lopen en ik dacht daar de timer waardes(TCNT1) te kunnen vergelijken bij rising of falling flank, maar dat werkt niet goed in de huidige code.

[jklu]

Ik ben bezig om een atmel NGW100 van 433Mhz te voorzien mbv de conrad 433Mhz rx/tx combi om zo mijn KaKu (simpele versie met ABCD en 3 buttons) aan te sturen.

Ik heb de RemoteSwitch C++ code omgezet naar C en met een testje gekeken of er hetzelfde patroon van 1-en , 0-en en usleeps uitkwam en dat klopte helemaal.

Als ik echter de 433Mhz tx aan sluit gebeurt er niks
Een ledje + 1K weerstand op dezelfde pin van de NGW gaat keurig aan en uit dus dat gedeelte werkt.

+V hangt aan de +3.3V, Ground aan de Ground en data aan de switch pin.
Handleiding heeft het over data ook aan ground in de duitse versie, engelse versie maakt er iets heel anders van.

Heeft iemand anders deze tx aan de praat gekregen op 3.3V ?

Andere slimme suggesties misschien ?

[Verwijderd]

Ik zou graag de temperatuur uit een draadloos weerstation uitlezen met een PIC, maar momenteel wilt het nog niet echt vlotten.

Ik heb zo'n 433MHz ontvangst-module uit de samenkopenactie van Niels nu rechtstreeks aan de EUART ingang van een pic gehangen, maar ik krijg er allemaal random codes uit.



En zo loopt het dus heel de tijd door.
Is er iemand die mij kan helpen om toch de goede codes binnen te krijgen?

[j-a-s-p-e-r]

Dat ding rechtstreeks aan de serial port van je PIC? Lijkt me ook niet zo'n strak plan. Beter gewoon aan en pin hangen en meten hoe lang de '1' en '0' duurt? Of bedoelde je dat ook maar lees ik heel scheel?

[Verwijderd]

Hallo, ik ben nu ook bezig met draadloze communicatie. Namelijk tussen twee ATmega's. Ik maak daarbij gebruik van deze modules:
http://ideetron.biedmeer....ry-44693/FSK-modules.html

Ik gebruik echter de 868MHz versie. Is er een nadeel om te communiceren op 868MHz i.p.v. op 433MHz? Ik ga van de week even testen, zal dan wel een verslag je posten hier. Misschien hebben anderen er nog wat aan.

[Fuzzillogic]

Verwijderd schreef op maandag 23 februari 2009 @ 21:21:
Ik zou graag de temperatuur uit een draadloos weerstation uitlezen met een PIC, maar momenteel wilt het nog niet echt vlotten.

Ik heb zo'n 433MHz ontvangst-module uit de samenkopenactie van Niels nu rechtstreeks aan de EUART ingang van een pic gehangen, maar ik krijg er allemaal random codes uit.

[afbeelding]

En zo loopt het dus heel de tijd door.
Is er iemand die mij kan helpen om toch de goede codes binnen te krijgen?

Die ontvangers hebben een "auto gain", ze zullen het signaal net zolang gaan versterken totdat ze signaal meten. En dat is dus meestal ruis. Dus troep. De zender zal echt iets moeten uitzenden alvorens je wat nuttigs kunt ontvangen. En gebruikt dat weerstation wel gewoon RS232-data??

Overigens ben ik het project niet vergeten. Maar iets met studie, werk, werk en tijd enzo Momenteel ben ik een Java-library aan het maken om m.b.v. het Firmata-protocol met de arduino te communiceren vanuit Java. Wel vervelend trouwens om te zien hoeveel van het toch al beperkte RAM de standaard Serial en Firmata-library al voor zich claimen.

Verder zag ik dat de de Karwei de KAKU-spullen vervangen heeft door HomeEasy. Vergelijkbaar spul, maar ook vergelijkbare techniek? Iemand ervaring ermee?

[Verwijderd]

Fuzzillogic schreef op maandag 23 februari 2009 @ 22:01:
[...]

Die ontvangers hebben een "auto gain", ze zullen het signaal net zolang gaan versterken totdat ze signaal meten. En dat is dus meestal ruis. Dus troep. De zender zal echt iets moeten uitzenden alvorens je wat nuttigs kunt ontvangen. En gebruikt dat weerstation wel gewoon RS232-data??

Overigens ben ik het project niet vergeten. Maar iets met studie, werk, werk en tijd enzo Momenteel ben ik een Java-library aan het maken om m.b.v. het Firmata-protocol met de arduino te communiceren vanuit Java. Wel vervelend trouwens om te zien hoeveel van het toch al beperkte RAM de standaard Serial en Firmata-library al voor zich claimen.

Verder zag ik dat de de Karwei de KAKU-spullen vervangen heeft door HomeEasy. Vergelijkbaar spul, maar ook vergelijkbare techniek? Iemand ervaring ermee?

Dit zijn nu dan ook de eerste stapjes die ik zet in het draadloze wereldje. Is er iemand die mij aan informatie kan helpen over hoe ik m'n weerstation zender zou kunnen ontvangen?

[Fuzzillogic]

Verwijderd schreef op maandag 23 februari 2009 @ 22:12:
[...]


Dit zijn nu dan ook de eerste stapjes die ik zet in het draadloze wereldje. Is er iemand die mij aan informatie kan helpen over hoe ik m'n weerstation zender zou kunnen ontvangen?

I've tried, and failed Het is ook afhankelijk van het merk. Het enige merk waar ik tot dusver enige informatie over gevonden heb is Oregon Scientific. Ik heb zelf een simpel Cresta-dingetje, maar hoe het signaal daarvan in elkaar steekt weet ik dus niet. Zie ook eerder in dit topic.

[Verwijderd]

nu eens geprobeerd door gewoon ook een zender aan te sluiten op de TX pin van m'n PIC en dan hetzelfde te ontvangen van wat ik zend, maar dat lukt ook niet. Krijg allemaal andere dingen te zien. Als ik de TX en RX pin gewoon aan elkaar verbind werkt het wel.

[Verwijderd]

Zonet even gekeken wat als code verzonden wordt door m'n weerstation. Daarom maar even met m'n 'scoop' rechtstreeks gekeken op de data die naar de 433MHz zender gaat.
Is er iemand die volgende code herkent? Ik meet dus 22.2°C, 22.1°C en 23°C.
De code op de afbeelding loopt nog een hele tijd verder, maar kan er mij iemand vertellen hoe ik de code kan decoderen?

[jasperbz]

Ik hoop dat iemand mij nog kan helpen.

Ik wil de tx433n zender koppelen aan m'n pc via USB om het kaku systeem te kunnen schakelen. ik heb al een zender die via de com-poort samenwerkt met winlirc. ik wil dit dus modificeren naar een USB aansluiting kan iemand mij hiermee helpen.

alvast bedank

Jasper

[j-a-s-p-e-r]

Dag naamgenoot,

Allereerst, Crossposten is niet gewenst. Niet meer doen, danku

Dan ten tweede; kijk eens hier naar (ca. 5 post boven jouw dubbelpost in het andere topic):

Verwijderd schreef op zaterdag 21 februari 2009 @ 22:49:
Leuk om te zien dat dit draadje na anderhalf jaar nog steeds leeft. Ondertussen heb ik e.e.a. in elkaar gesleuteld om via een universele AB of de PC (Met EventGhost o.i.d. ) alle KAKU spullen aan te sturen. Het geheel is opgebouwd rondom een Arduino en volledig gedocumenteerd..

Voor wie meer wil weten, kijk eens op:

http://home.kpn.nl/pkt/Nodo/index.html

Redelijk wat jij wil. Of gebruik een USB-RS232 converter van FTDI (met bitbang ondersteuning). Winlirc doet namelijk niet aan netjes serieel maar aan 'snel aan uit schakelen'. Daarom werken normale kabeltjes hier niet mee.

[Shorty24]

@Tomw: Is het je ooit nog gelukt het weerstation-protocol te decoderen?
Ik ben zelf met een projectje bezig waarvoor ik al behoorlijk wat protocollen heb ontcijfert. Indien het je gelukt is zou ik graag je info ook in mijn project verwerken. Is het nog niet gelukt? Wellicht is het signaal wat je ontvangt gelijk aan een protocol die ik al (gedeeltelijk) oncijfert heb...

gr. Sander

[ Voor 68% gewijzigd door Shorty24 op 23-03-2009 16:13 ]

[Verwijderd]

@ shorty24:

Heb je die resultaten ergens staan? Heb daar wel interesse in!

[Shorty24]

@veilingas:
Op: http://arduinoha.googlecode.com staat mijn sourcecode.

[Verwijderd]

Shorty24 schreef op maandag 23 maart 2009 @ 16:11:
@Tomw: Is het je ooit nog gelukt het weerstation-protocol te decoderen?
Ik ben zelf met een projectje bezig waarvoor ik al behoorlijk wat protocollen heb ontcijfert. Indien het je gelukt is zou ik graag je info ook in mijn project verwerken. Is het nog niet gelukt? Wellicht is het signaal wat je ontvangt gelijk aan een protocol die ik al (gedeeltelijk) oncijfert heb...

gr. Sander

Dat is me na veel zoekwerk nog steeds niet gelukt. Heb je een vermoeden van welk protocol gebruikt is?

[Verwijderd]

Over het cresta weerstation protocol. Het lijkt me een eitje hoor. Ik heb er even naar gekeken en kan nu de pakketjes van een temperatuur sensor naar mijn pc (over r232, com poort) mbv avr chip die de data ontvangt via een standaard 433MHz receiver.
Wat zeker is na de eerste stappen.
Er wordt manchester code gebruikt (clk is ongeveer 2KHz) om de data serieel over te sturen. Elke byte bestaat uit 9 bits, de laatste lijkt altijd "1" en kan misschien voor fout controle gebruikt worden.
De sensor stuurt 3x per keer (elke 45 seconden) hetzelfde pakje van 10 bytes dus 30 bytes data totaal) in 1 stream van plm 1 seconde.
De eerste analyse van de data (thermo/hygro):
Byte 0: 8Ah (voor alle sensoren die ik heb UV, Temp/hydro, Regen niveau etc.
Byte 1: Identificatie byte die afhankelijk is van het gekozen kanaal (op de sensor) maar niet altijd hetzelfde is voor een gekozen kanaal. (Hij veranderd als je de sensor reset naar een of andere functie van het gekozen kanaal, maar blijft hetzelfde zolang de sensor niet gereset wordt).
Byte2: Sensor type… 45 voor thermometer / hygrometer, BB voor UV….
Byte3: Lijkt een nummer wat het pakketje beschrijft. Lijkt niet nodig voor data decoder.
Byte 4,5: Versleutelde informatie over de temperatuur. Ik heb even vlug een paar waarden gemeten en ik weet ZEKER dat het een EITJE is om die code te kraken.. Simpele substitutie op BCD niveau zou al werken.. Ik meet later nog wel wat waarden en zal dat varkentje even wassen 
Byte 6,7: Hygro bytes zelfde verhaal als byte 4,5
Byte 8,9: Lijken een soort checksum..

Als jij meer weet over het protocol, mail me dan (dat spaart mij werk) op [e-mail]
Groetjes
Ruud

[Verwijderd]

Weer over het cresta protocol. (Thermo/hygro sensor)

Byte 8 is inderdaad een checksum. De xor van byte 1 t/m 8 moet 0 geven (dus niet byte 0 "8A" mee nemen, en niet byte 9).

De sleutel is inderdaad een simpele substitutie van BCD.

Byte 4 en 5 temperatuur, Byte 6, vocht percentage. Byte 7 geeft vermoed ik het comfort niveua aan.

Gezien heb ik AA voor alles OK, AE voor koud, 56 voor koud en droog.

Hier wat pseudo code... Dit moet prima werken.

BYTE Translate4Bits( BYTE b)
{
Byte table[]={1,2,7,4,?,?,?,8,9,?,?,?,5,6,3,0}; // ? komen niet voor!
Return table[b&0x0f];
}

ShowTemp (BYTE *Packet)
{
BYTE a= Packet[5];
if ( a & 0x8) a ^= 0xf0;
a = TranslateBits(a & 0x0f);

BYTE b= Packet[4];
if ( b & 0x8) b ^= 0xf0;
c = TranslateBits(b & 0x0f);
b = TranslateBits(b >> 4);
printf("Temperatuur is %x%x,%x\n" a,b,c);

a = Packet[6];
if ( a & 0x8) a ^= 0xf0;
b = TranslateBits(a & 0x0f);
a = b | (TranslateBits(a>>4)<<4);
printf("Vocht perc. is %x\n" b);
}

De negatieve temp werkt nog niet.. Mijn vriezer staat te ontdooien..

Gr
Ruud

[arnob]

Verwijderd schreef op dinsdag 21 april 2009 @ 09:02:
Over het cresta weerstation protocol. Het lijkt me een eitje hoor. Ik heb er even naar gekeken en kan nu de pakketjes van een temperatuur sensor naar mijn pc (over r232, com poort) mbv avr chip die de data ontvangt via een standaard 433MHz receiver.

huh!? Super!
Er zijn een aantal mensen mee bezig geweest (en niet alleen op tweakers) en die konden er niets van maken. Hoe krijg je dat nu zo voor elkaar? En wat voor apparatuur heb je gebruikt om het uit te vogelen?
Werk je met een 433 ontvanger met of zonder auto-gain?

Heb je trouwens gezien wat het meetstation doet bij het scannen naar apparaten? Zend deze uit of ontvangt deze alleen? (maakt dus een lijst van die byte 1 ID's)

Dit is zeer interessant. Ik heb ook een cresta weerset en wil deze ook zelf uitlezen. Veel gelezen over mensen die problemen hadden met de usb versie. usb massa verschillen e.d. wat storing gaf.
Zo wordt het monitoren/loggen een haalbare zaak.

google termen:
Irox PRo-EC / Mebus / Honeywell / TFA / Cresta WXR-815 / Conrad / Bresser / RSB
TE923 / TE923W / TE924 / WXR-815 / WXR-815LM / NEXUS / SINUS / PTM980 / DV918 / 4Cast

[Verwijderd]

Hoi Arnob,

Ik had al een tijdje met het idee gespeeld om een interface programma voor mijn sensoren met de PC te maken, maar heb dit op de lange baan geschoven, totdat ik toevallig over dit forum struikelde. Hier is hoe ik te werk gegaan ben.

Ik heb een oude 433MHz receiver uit een la gewist (ooit eens bij conrad gekocht voor een paar knaken). Ik denk dat het ontvangertje over een zeer primitieve AGC beschikt.
Vervolgens heb ik een atmega8 op een breadboard geprikt en gekoppeld met de ontvanger en de compoort van de PC. Ik heb toen een zeer kort asm programmaatje geschreven die alle puls-pauze info als ascII naar de pc (hyperterminal) stuurde en herkende eigenlijk meteen dat het om Manchester code moest gaan. Dus heb ik een kort asm proggy geschreven wat manchester code decodeert en de gedecodeerde data naar de PC gestuurd. Na wat knoeien met shift-richting , de polarity en het aantal bits per byte (dit kan je eigenlijk simpel uit de ontvangen data halen) was het alleen nog maar een kwestie van bekende temperaturen (op de display van de sensor) kloppend maken met de ontvangen data.

Dit was echt makkelijk. sensor even in de koelkast en daarna op je buro. Hij warmt dan langzaam op, je noteert de afgelezen temperatuur bij de ontvangen data. Je ziet dan meteen dan meteen aan de herhalende data bij sprongen van 1 graad (met wat tussen data) dat het om BCD moet gaan)... En ook dat de data voor elke digit op vergelijkbare wijze versleuteld is... etc.


Ik denk dat ik er alles bijelkaar een uurtje of 3-4 mee bezig geweest ben. Ik denk ook dat anderen die er mee bezig zijn geweest het niet gevonden hebben omdat ze de manchester code niet herkend hebben.

Mijn plan is nu om een apparaatje te maken met een atmega, ontvanger en wat sram zodat ik al mijn weer-info altijd op de PC kan waarnemen.

Gr
Ruud

[Verwijderd]

Sorry, dat vergeet ik nog. Ik weet niet zeker of het meetstation ooit iets uitzendt, Ik heb in ieder geval niets ontvangen. Maar dat is ook niet nodig. Alle sensoren varieren de periodes tussen twee verschillende uitzendingen zodat de kans eigenlijk nul is dat twee uitzendingen ALTIJD samen vallen. Soms vallen ze wel samen, maar zelfs dan krijg ik op hyperterminal vaak een juiste uitlezing.

[Verwijderd]

Nou, nou... Ik blijf lullen

De vriezer doet het weer.. Dus de min is gevonden in bit 7 van byte 5. Mits je de decoder routine hier beneden gebruikt.

Het is trouwens aan te raden om alle bytes (behalve de checksum en header byte) door de decoder te sturen. Verschillende bits zijn dan makkelijker te interpreteren..

Hoogste nibble van byte 5 = 4 als negatief, 0xC als positief.
Laagste nibble van byte 5 = tientallen van graden C.
Hoogste nibble van byte 4 = eenheden van graden C.
Laagste nibble van byte 4 = tienden van graden C.

Byte 6 geeft vocht perc. BCD coded.


De decoder die ik gebruik, sorry. Is in asm.

DecNib:
push tmp1
ldi tmp1,4
eor WR1,tmp1
subi WR1,3
ldi tmp1,7
and tmp1,WR1
dec tmp1
andi tmp1,8
eor WR1,tmp1
ldi tmp1,3
and tmp1,WR1
inc tmp1
andi tmp1,4
eor WR1,tmp1
pop tmp1
ret

; Decodeert byte in register WR1 naar WR1
; Sloopt register tmp1

DecodeByte:
ldi tmp1,0xf0 ;Mask / xor value
sbrs WR1,3
eor WR1,tmp1 ;Complement upper bits
and tmp1,WR1 ;Upper in tmp1
eor WR1,tmp1 ;Lower in WR1
swap tmp1
rcall DecNib ;Decode lower BCD
push WR1
mov WR1,tmp1
rcall DecNib ;Decode upper BCD
swap WR1
pop tmp1
or WR1,tmp1 ;Combine upper/lower
ret

[Verwijderd]

Ik heb alles kort samen gevat in een PDF filetje. Ik hoop niet dat me baas dit leest.

http://members.upc.nl/m.beukelaar/Crestaprotocol.pdf

[DirkB19]

@Oopsje : S C H I T T E R EN D WERK man ! Echt super ! En respect !
Hier zat ik al lang op te wachten.
Had zelf het vage plan om het uit te zoeken maar het ontbrak me aan tijd en goesting.

K'heb hier een Cresta weerstation, een ATMEGA8, een 433RX en kan aan de slag.
Heb je toevallig de ASM of beter de ASP files van je werk ?
Dat zou echt de max zijn, dan kan ik gelijk starten om het aan te passen naar mijn domotica-project.

GRTZ,
DirkB

[Folie]

Bump

Heb het topic in een tijdsspanne van enkele weken doorgelezen, dus ik weet niet meer precies of het al vermeld is, maar een Elro dimmer kitje werkt via de KAKU library van Fuzzylogic

Hartelijk bedankt voor het mooie werk jongens!

[Verwijderd]

Hoi,
ik ben bezig met 433 Mhz en Atmega processoren (geen Arduino).
Ik heb een setje van klik-aan klik-uit (de nieuwe variant) en gebruik een module uit een oude bel (volgens mij) om te ontvangen, plus atmega8 op 8mhz (intern) om te decoderen. Als zender gebruik in nu de KaKu afstandbediening maar een oude bel werkt ook prima (zij het niet op 3.3v).

Alles werkt prima met een zelfgebakken Sony-IR achtige code, maar ik heb een hele lompe methode gebruikt om de benodigde KaKu codes te genereren. Ik heb eigenlijk alles opgenomen op mijn "scope" (rf-module aan soundcard) en het signaal puls voor puls nagemaakt.

Kan iemand me vertellen hoe deze nieuwe KaKu code precies werkt zodat ik een intelligentere oplossing kan maken (en wat ruimte in mijn chippie over kan houden? Ik herken het niet, het bevat korte en lange positieve en negatieve pulsen... Ik snap er echt helemaal niks van.

Ik hoop dat iemand kan helpen!
Groeten,
Dennis

PS: Als het klaar is zal ik het op het web zetten zodat andere Atmel liefhebbers zonder Arduino er ook wat aan hebben. (Allemaal C code, zowel de zender als de ontvanger)

[sunoke]

Een Arduino is gewoon een atmega168 of atmega328 met een bootloader en een eenvoudige ontwikkelomgeving met wat macro's. Als je die Arduino code neemt kun je die redelijk eenvoudig ombouwen. Je zou er ook voor kunnen kiezen om een Arduino na te bouwen met zo'n Atmega.

Als je hier op tweakers rondkijkt vind je redelijk wat informatie over hoe het signaal in elkaar zit. Het is redelijk simpel.

[Verwijderd]

Hoi, ik had al bedacht van mijn chippie ene arduino compatibel board te maken, maar ik heb er geen zin in, ben een beetje ene purist, wat niet nodig is, is voor mij niet nodig. (Ik zeil ook een boot zonder ballast, dus waarom mijn code wel ;-)

De info die ik hier vind is voor mijn gevoel niet correct. Van alles over tri-state en "tritsen" volgens mij is dat het niet. Hoe dan wel:
ff in het kort telegram stijl, ik zit bij m'n schoonouders!

KAKu code:
1= ||_ 0= |_| |=330us _=1229us Single bit=2000us startbit = |_ _ (2910us) interpulse gap=208us
Stopbit (=timed out second pulse on 0, same as start bit) time between repeats = 661ms
code train = 32bit ex start en stop
CH1 AAN = S 1111 0110 0100 1110 1011 1000 0110 1111 S
CH1 UIT = S 1111 0110 0100 1110 1011 1000 0111 1111 S
CH2 AAN = S 1111 0110 0100 1110 1011 1000 0110 1110 S
CH2 UIT = S 1111 0110 0100 1110 1011 1000 0111 1110 S
GRP --- = S 1111 0110 0100 1110 1011 1000 0101 1111 S


Groeten,
Dennis

ps "tritsen" zijn dus toevallige samenlopen van een 1 gevolgd door een 0;
pps ik kan 1 en nul omgekeerd hebben, kan iemand me verbeteren als het zo is?

[Fuzzillogic]

Je hebt het nou over de oude (non-A) KaKu-codes? Sorry, maar daar is toch echt sprake van een IC met tri-state ingang. Die info komt uit de datasheets van de gebruikte IC's. Dat ze ook op een ander manier te interpreteren zijn zal best werken, daar niet van. De code in de TS klopt gewoon.

Let wel: de nieuwe A-serie KaKu-remotes gebruiken een andere code. Al die zenders hebben in principe een eigen unieke code.

[jurp5]

Iemand die ervaring heeft met HomeEasy apparatuur en dan specifiek het setje met de HE300WEU afstandsbediening?

Ik heb op dit moment geen scoop meer tot mn beschikking, maar deze codes heb ik kunnen opvangen en deze werken als ik ze 'hard' uitzend mbv een arduino + 433Mhz zender:

kanaal 0 aan:
1100011110010111011010100011110110101100011101110010001111
kanaal 0 uit:
1100011110010111011010100011110110101100011101101010001111

(1 = 275 us hoog 1225 laag, 0 = 275 us hoog 275 us laag)

Ik begrijp de codering niet helemaal, het zou manchester codering moeten zijn volgens de Arduino Playground, maar deze codes voldoen daar helemaal niet aan (de aan/uit bit zo te zien trouwens wel)
ze zijn sowieso 58 bits lang ipv 64 bits.

Iemand die weet op welke manier dit gecodeerd is?

Update:

zo schakel ik kanaal 1(dus 2 op het zendertje):
1100011110010111011010100011110110101100011101110010010111
ik word er niet veel wijzer van, is het nou gedeeltelijk manchestercode(want aan is 10 en uit is 01), of wat

Hopelijk weet een van jullie wel hoe het zit

Nog ff voor de goede orde alles op een rijtje:

code:

1100011110010111011010100011110110101100011101110010001111 #kanaal 0 aan
1100011110010111011010100011110110101100011101101010001111 #kanaal 0 uit
1100011110010111011010100011110110101100011101110010010111 #kanaal 1 aan
1100011110010111011010100011110110101100011101101010010111 #kanaal 1 uit
1100011110010111011010100011110110101100011101110010011011 #kanaal 2 aan
1100011110010111011010100011110110101100011101101010011011 #kanaal 2 uit
1100011110010111011010100011110110101100011101110010011101 #kanaal 3 aan
1100011110010111011010100011110110101100011101101010011101 #kanaal 3 uit
1100011110010111011010100011110110101100011101110010100111 #kanaal 4 aan
1100011110010111011010100011110110101100011101101010100111 #kanaal 4 uit
1100011110010111011010100011110110101100011101110010101011 #kanaal 5 aan
1100011110010111011010100011110110101100011101101010101011 #kanaal 5 uit
1100011110010111011010100011110110101100011101110010101101 #kanaal 6 aan
1100011110010111011010100011110110101100011101101010101101 #kanaal 6 uit
1100011110010111011010100011110110101100011101110010110011 #kanaal 7 aan
1100011110010111011010100011110110101100011101101010110011 #kanaal 7 uit
1100011110010111011010100011110110101100011101110010110101 #kanaal 8 aan
1100011110010111011010100011110110101100011101101010110101 #kanaal 8 uit
1100011110010111011010100011110110101100011101110010111001 #kanaal 9 aan
1100011110010111011010100011110110101100011101101010111001 #kanaal 9 uit
1100011110010111011010100011110110101100011101110010000111 #kanaal 10 aan
1100011110010111011010100011110110101100011101101010000111 #kanaal 10 uit
1100011110010111011010100011110110101100011101110010001011 #kanaal 11 aan
1100011110010111011010100011110110101100011101101010001011 #kanaal 11 uit
1100011110010111011010100011110110101100011101110010001101 #kanaal 12 aan
1100011110010111011010100011110110101100011101101010001101 #kanaal 12 uit
1100011110010111011010100011110110101100011101110010010011 #kanaal 13 aan
1100011110010111011010100011110110101100011101101010010011 #kanaal 13 uit
1100011110010111011010100011110110101100011101110010010101 #kanaal 14 aan
1100011110010111011010100011110110101100011101101010010101 #kanaal 14 uit
1100011110010111011010100011110110101100011101110010011001 #kanaal 15 aan
1100011110010111011010100011110110101100011101101010011001 #kanaal 15 uit

Update: heb wat codes toegevoegd waar ik door experimenteren achter ben gekomen.. Zie er niet echt logica in...

bits 2-6 van rechts regelen het kanaal

[ Voor 75% gewijzigd door jurp5 op 28-12-2009 11:30 . Reden: kanaal 4,5,6,7,8,9 ]

[Verwijderd]

fuzzi, misschien hebben we het dan over verschillende apparaten. Ik heb ze niet bij de hand maar zal eens kijken. Hoe kan ik zien uit welke serie mijn setje komt? De signalen die ik zie op mijn scope (soundcard) lijken niet op de beschreven manchester codering. Momenteel heb ik een zelfgeschreven zend routine in mijn AVR die zich ook niets van tri-state aantrekt en zeer betrouwbaar werkt. Vandaar dat ik op zoek was naar een andere verklaring. Maar misschien praten we nu wel heel erg langs elkaar heen...

Mijn KAKU setje is de 2300W 2x stekker schakelaars met mini AB (op 3v knoopcel) van de (GAMMA) bouwmarkt, misschien wordt het dan duidelijk welk setje ik bedoel.
[edit]
De ontvangers leren eerst de code van de zender, daar reageren ze vervolgens op.
Ik denk dus dat dit wel de A serie is waar jij aan refereert. Volgens mij is het me dus nu gelukt ze te decoderen, nu een kwestie van een programmaatje maken en aan de slag. Volgens mij heb ik de 1en en de 0en verwisseld, maar dat komt goed.

[ Voor 20% gewijzigd door Verwijderd op 27-12-2009 19:52 ]

[Fuzzillogic]

Aha, als je de ontvanger moet leren dan is het waarschijnlijk dat de zender uit de A-serie komt ja, en die zijn inderdaad heel anders. Het zou geweldig zijn als het lukt om dit te decoderen - hoewel ik me afvraag hoe nuttig dat is met unieke codes; het gaan dan puur om het herkennen lijkt me?

[Verwijderd]

tja, als ik de code bekijk die ik krijg (en ik inverteer de bits) dan zie ik in ieder geval dat de laatste nibble waarschijnlijk een switch adres is en het voorlaatste nibble een code voor de instructie. Wellicht is het hele eerste deel dan een random code die per afst. bed. verschilt. Zou wel simpel zijn.

Heeft iemand hier nog een trace, dwz plaatje van scope, soundcard o.i.d., (geen analyse van lirc o.i.d.) van het signaal van zo'n type "A" afst.bediening? Dan zou ik ze naast elkaar kunnen leggen om naar de verschillen en overeenkomsten te zoeken. Ik hou me aanbevolen, dan wil ik best kijken of ik de code kan decoderen. Ik wil ook zelf afstandsbedienbare apparaatjes maken, en waarom ook niet met deze code.

[jurp5]

Hier nog ff een duidelijke tabel van de bits die het kanaal bepalen, iemand die dit wel begrijpt?

kanaal	bits
0	00111
1	01011
2	01101
3	01110
4	10011
5	10101
6	10110
7	11001
8	11010
9	11100
10	00011
11	00101
12	00110
13	01001
14	01010
15	01100

Graag kom ik er ook achter waar de group flag zit en hoe het precies zit met de unieke code van de transmitters

De rest van de info staat in m'n vorige bericht, waaronder ook het volledige bericht wat de transmitter verzend

[LED-Maniak]

er hoort nog een hele waslijst voor te zitten die inderdaad de zender aanduid.

In de PT2262 handleiding kan je precies zien hoe het is opgebouwd en wat welke bit betekend

[ Voor 38% gewijzigd door LED-Maniak op 28-12-2009 16:07 ]

[jurp5]

LED-Maniak schreef op maandag 28 december 2009 @ 16:01:
er hoort nog een hele waslijst voor te zitten die inderdaad de zender aanduid.

In de PT2262 handleiding kan je precies zien hoe het is opgebouwd en wat welke bit betekend

Ik weet niet of die PT2262 in mn HomeEasy zenders zit, maar het signaal wat ik heb bestaat uit 58 bits, terwijl een code frame van de PT2262 bestaat uit 4 code words van 13 bits (52 bits dus). dat komt dus niet overeen.

zie http://gathering.tweakers.net/forum/view_message/33170813 voor de opbouw van de signalen

[Megamind]

Hmm, ik heb hier van de Media Markt een Elro setje AB440. Maar helaas werkt de library van Fuzzylogic niet, maar ik weet niet zeker of mijn 433 zendertje ook wel werkt, hoe kan ik dit makkelijk testen? Ik heb helaas geen scope hier

[LED-Maniak]

hang hem aan je microfoon ingang met een audioscope op de PC. Dan krijg je ook de signalen te zien

[jurp5]

Niemand een idee over mijn HomeEasy setje?

http://gathering.tweakers.net/forum/view_message/33170813

[Verwijderd]

Jurp5,
In je signaal omschrijving zeg je:

(1 = 275 us hoog 1225 laag, 0 = 275 us hoog 275 us laag)

Als het om een Manchester codering gaat, kan dit nooit het signaal zijn. Bij Manchester codering varieert zowel de lengte van de hoge als de lage puls.

Hoe kom je aan deze info, heb je dat gemeten?

Gr
Ruud

[jurp5]

Verwijderd schreef op maandag 04 januari 2010 @ 09:54:
Jurp5,
In je signaal omschrijving zeg je:

(1 = 275 us hoog 1225 laag, 0 = 275 us hoog 275 us laag)

Als het om een Manchester codering gaat, kan dit nooit het signaal zijn. Bij Manchester codering varieert zowel de lengte van de hoge als de lage puls.

Hoe kom je aan deze info, heb je dat gemeten?

Gr
Ruud

Deze info heb ik van de arduino playground en heb ik ook zelf gemeten mbv een scoop.
Deze gegevens leken te kloppen omdat de twee bits die aan en uit aan geven voor aan op 10 staan en voor uit op 01. Maar ik ben er niet 100% zeker van natuurlijk, want een expert op dit gebied ben ik ook weer niet

En hoe ik het nu geprogrammeerd heb kan ik gewoon alle 16 'kanalen' aansturen, alleen is het wat vervelend dat ik bepaalde dingen hardcoded heb staan('kanalen') en ik nog niet de volledige opbouw van het signaal snap, ik post vanavond even de group code die de groupbutton op de homeeasy remote uitstuurt. Die verschilt weer heel wat van een standaard signaal. Ik zou het fijn vinden als ik er achter kwam hoe het signaal nou precies opgebouwd was.

[Megamind]

Ik ben bang dat de setjes van Elro niet met Fuzzillogic's code werken. Ik heb geprobeerd de codering eruit te halen, maar dat gaat mij echt boven m'n pet. Het gaat om de setjes van de Mediamarkt (3 dozen + AB voor 9,95) Elro AB440

[Fuzzillogic]

Valt te achterhalen met welke chipset het spul werkt? Ik heb onlangs zo'n Elro-set cadeau gegeven aan iemand, ik kan tzt eens met scope langsgaan om te zien of ik er wat wijzer van wordt. De kans bestaat echter dat het enkel een timing-issue is.

[Megamind]

De AB heeft een HX2262, 2008Q proc staat verder op het printje nog MY-4X2.01Bt1, MXG-08.07.15.

[Fuzzillogic]

Ah, de 2262, dat is precies de gewenste chip . Er zijn 3 factoren van belang: de duur-eenheid van een pulsje (dus de duur van het kortste pulsje dat je tegenkomt, 0 of 1), hoe de knoppen de ingangen van de zender beinvloeden: maken ze de ingang laag of juist hoog, en hoe de ongebruikte ingangen aangesloten zijn: zijn ze laag, hoog of floating?

De base-class van de RemoteSwitch library is (voor mij iig ) makkelijk aan te passen hiervoor. Zonder scope wordt het wel lastig, maar de periode is in principe uit te rekenen, en met een multimeter zijn de ingangen van de 2262 te bekijken.

Het kan dus waarschijnlijk wel, maar zelf heb ik niet direct de beschikking over de Elro-set...

[Megamind]

Zijn deze dingen niet met het Processing appje te achterhalen?

[Fuzzillogic]

Megamind schreef op woensdag 06 januari 2010 @ 00:01:
Zijn deze dingen niet met het Processing appje te achterhalen?

Ja, als je dat aan de praat hebt gekregen dan kun je al een heel eind komen. Processing krijgt de timings door, die kun je dan wel makkelijk onderscheppen (of kijk gewoon met de COM-log van de Arduino IDE). Uit het grafiekje valt vervolgens wel de code te herleiden. Deze datasheet helpt daar wel bij.

[Megamind]

Ja processing werkt gewoon, alleen snap ik 1 ding niet. Als ik de knop van mijn AB ingedrukt houd krijg ik netjes een grafiekje, maar altijd is er 1 hoog stukje dat elke 0,5 sec iets langer en dan weer iets korter wordt, kan misschien foutje zijn in de ontvanger?