DIY: Itho ventilatie aansturen via 868Mhz transmitter

[edjeed]

Ik denk dat ik last heb van omgevings noise, waardoor ik geen valid SYNC woord ontvang.
Vanavond ga ik hetvolgende testen:

Wat mij opvalt is dat de 'RX filter BW' nu wordt ingesteld op 812.5Khz (message1) en 325kHz (message2).
Volgens mij kan dit een stuk kleiner zijn, namelijk:

Message1:
2*Deviation +Data rate = 2* 25 +8 dus ongeveer 58kHz. (dichtsbijzijnde mogelijke waarde is 67.7 Khz)

Message2:
2*Deviation +Data rate = 2* 50 +38 dus ongeveer 138kHz. (dichtsbijzijnde mogelijke waarde is 162.5 Khz)

En checken of de carrier-sense boven de treshold waarde is voor het ontvangen van data.

[ Voor 15% gewijzigd door edjeed op 10-01-2017 13:13 . Reden: Verschil tussen Message1 en Message2 ]

[racquemis]

Ben benieuwd naar je bevinden Had zelf al even mee gespeeld maar geen resultaat.

Iets anders, Hoe lang heeft het trouwens bij jullie geduurd voordat jullie de c1101 in huis hadden. Het duurt bij mijn wel erg lang. 10 december besteld.

[sjimmie]

racquemis schreef op dinsdag 10 januari 2017 @ 21:14:
Ben benieuwd naar je bevinden Had zelf al even mee gespeeld maar geen resultaat.

Iets anders, Hoe lang heeft het trouwens bij jullie geduurd voordat jullie de c1101 in huis hadden. Het duurt bij mijn wel erg lang. 10 december besteld.

Dat is lang maar de vele aliexpress en ebay bestellingen hier varieerden van 10 dagen tot iets meer dan 6 weken. Dus 1 maand is nog niet heel vreemd, zeker niet gezien de extra drukte door de feestdagen.
(als ik iets goedkoops vlot wilde hebben bestelde ik er 2 bij verschillende shops)

[racquemis]

Zal je net zien, De CC1101 lag vandaag in de bus. Ik kan aan de slag.

[rorie]

Spullen zijn hier ook eindelijk binnen, Nodemcu v3, c1101 en een DHT22 sensor. Met weinig Arduino ervaring ben ik gestart met het voor elkaar krijgen van het uitlezen van de DHT22 en dit via een webserver te publiceren. Dit is gelukt en draait nu al een nachtje stabiel. Mijn volgende stap is om deze DHT22 data via MQTT aan Domoticz door te geven. Is er hier iemand die een zijn of een stukje voorbeeldcode heeft om de uitgelezen waardes van de DHT22 via MQTT naar domoticz te sturen?

[sjimmie]

rorie schreef op donderdag 12 januari 2017 @ 13:21:
Mijn volgende stap is om deze DHT22 data via MQTT aan Domoticz door te geven. Is er hier iemand die een zijn of een stukje voorbeeldcode heeft om de uitgelezen waardes van de DHT22 via MQTT naar domoticz te sturen?

Dit lijkt me daarvoor een betere plek: Het grote ESP topic of [Discussie] Arduino-topic

[ Voor 6% gewijzigd door sjimmie op 12-01-2017 14:48 ]

[ThinkPad]

Yep Laten we ons hier focussen op het aansturen/uitlezen van de Itho.

[racquemis]

Met de nieuwe CC1101 met goede antenne krijg ik wederom geen goede data binnen als ik op de knop van de remote druk. Iemand een idee?

Elke keer als ik op de knop van de remote druk krijg ik in m'n serial monitor wel netjes reeksen getallen. De sync bytes lijken dus gewoon goed geïnterpreteerd te worden.

[ Voor 39% gewijzigd door racquemis op 13-01-2017 07:13 ]

[sjimmie]

racquemis schreef op donderdag 12 januari 2017 @ 22:23:
Met de nieuwe CC1101 met goede antenne krijg ik wederom geen goede data binnen als ik op de knop van de remote druk. Iemand een idee?

Elke keer als ik op de knop van de remote druk krijg ik in m'n serial monitor wel netjes reeksen getallen. De sync bytes lijken dus gewoon goed geïnterpreteerd te worden.

Lijkt er bijna op dat jouw remote iets anders doet dan wat we "verwachten"...

[racquemis]

Of misschien een issue met de SPI communicatie? de sync bytes worden intern in de CC1101 verwerkt dat gaat goed want het leesregister word gevuld.
Voor zover ik kan zien is de SPI frequentie 1 Mhz, ver onder de max. 10 Mhz gespecificeerd in de datasheet van C1101.
Een andere mogelijk is dat ik wellicht teveel voltage drop heb waardoor willekeurig 1tjes als 0tjes of omgekeerd worden gezien tijdens het uitlezen.

Ik heb een logic analyzer in bestelling. Op de printplaat van de remote geidentificeerd waar ik MOSI en MISO vanaf kan pakken dus ik ga dat maar even analyzeren. Weten we in iedergeval of mijn remote echt wat anders uitstuurt.

[sjimmie]

racquemis schreef op vrijdag 13 januari 2017 @ 12:28:
Of misschien een issue met de SPI communicatie? de sync bytes worden intern in de CC1101 verwerkt dat gaat goed want het leesregister word gevuld.
Voor zover ik kan zien is de SPI frequentie 1 Mhz, ver onder de max. 10 Mhz gespecificeerd in de datasheet van C1101.
Een andere mogelijk is dat ik wellicht teveel voltage drop heb waardoor willekeurig 1tjes als 0tjes of omgekeerd worden gezien tijdens het uitlezen.

Ik heb een logic analyzer in bestelling. Op de printplaat van de remote geidentificeerd waar ik MOSI en MISO vanaf kan pakken dus ik ga dat maar even analyzeren. Weten we in iedergeval of mijn remote echt wat anders uitstuurt.

Je gebruikt toch gewoon een esp8266 zonder fratsen? Dan kan ik me niet voorstellen dat je een SPI issue hebt. Tenzij je andere pinnen gebruikt dan default of levelshifters ofzo. Ik heb het zelfs werkend gehad op een "trage" 8MHz 3.3V arduino. Ik heb wel eens van 1 van de onderzoek-starters gehoord dat hij issues had met wat te lange draden, maar de cc1101 die ik jou stuurde heeft hier gewoon gewerkt, en de cc1101 die ik gebruik heeft diezelfde lengte.

[racquemis]

Ja het is gewoon een normale ESP-12F, geen level shifters, gewoon hetzelfde qua aansluiting zoals vermeld in de library.

Vreemd, ik ga het ook nog wel even proberen rechtstreeks op een arduino uno. Wil toch ook graag kunnen ontvangen.

[sjimmie]

racquemis schreef op vrijdag 13 januari 2017 @ 13:53:
Ja het is gewoon een normale ESP-12F, geen level shifters, gewoon hetzelfde qua aansluiting zoals vermeld in de library.

Vreemd, ik ga het ook nog wel even proberen rechtstreeks op een arduino uno. Wil toch ook graag kunnen ontvangen.

Kijk uit, een Arduino UNO is 5V...

[racquemis]

II'm aware, kwestie van wat level shifters toepassen. Komt goed
Met rechtstreeks bedoelde ik meer zonder breadboard. Kan ik slechte verbindingen uitsluiten.

[racquemis]

Ik geef het op, laatste poging gedaan met de esp8266. Dit maal met een breadboard power supply.
Had ik beter niet kunnen doen. ESP8266 stuurt nu nog alleen nog maar wartaal over serieel en krijg mn niet meer online. Die is dus defect

[sjimmie]

racquemis schreef op vrijdag 13 januari 2017 @ 18:14:
Ik geef het op, laatste poging gedaan met de esp8266. Dit maal met een breadboard power supply.
Had ik beter niet kunnen doen. ESP8266 stuurt nu nog alleen nog maar wartaal over serieel en krijg mn niet meer online. Die is dus defect

Frustrerend, maar niet het einde.
Eerst alvast een simpele sketch (blink of helemaal leeg) in ce Arduino IDE openen.
Spanningsloos maken, flashknopje ingedrukt houden, aan serieel hangen, flashknopje loslaten, sketch uploaden. Werkt vrijwel zeker binnen een paar pogingen.

[rorie]

Na een avondje solderen en testen wil het maar niet werken, mijn Itho geeft geen reactie, iemand met wat tips?

Wat heb ik gedaan, alles netjes gesoldeerd en aangesloten op mijn ESP8266 LoLin V3. Alle draadjes zijn korter dan 10 cm. Daarna de ESP8266 voorzien van de code van Whizzer, de join leek goed te gaan, gezien de serial output. Mijn Itho ging bijna direct in de hoogste stand, zou een bevestiging kunnen zijn dat de join succesvol was maar dat weet ik niet zeker. Hierna probeerde ik hem via de web interface op low of medium te krijgen maar mijn Itho bleef op de hoogste stand draaien. Via de serial kreeg ik wel netjes terug dat hij op low of medium gezet moet zijn maar niet dus.

Daarna de orginele versie https://github.com/supers...oFanRFT/IthoEcoFanRFT.ino geprobeerd, deze kan voor zover ik kan zien alleen ontvangen. Dit gebeurd dus ook, als ik met mijn andere remote wissel van low naar medium dan zie ik wat berichtjes voorbij komen via de serial.

Iemand dezelfde ervaring dat zijn Itho bij een join op high gaat?

Serial output bij een low vanaf de andere remote

message1 not ok=byte6 (82/51)
message1 not ok=byte7 (211/43)
message1 not ok=byte8 (53/84)
message1 not ok=byte9 (51/205)
message1 not ok=byte13 (82/83)
message1 not ok=byte14 (171/83)
message2 not ok=byte17 (154/89)
message2 not ok=byte18 (102/154)
message2 not ok=byte19 (149/153)
message2 not ok=byte20 (165/170)
message2 not ok=byte21 (169/105)
message2 not ok=byte42 (89/90)
message2 not ok=byte43 (106/90)
message2 not ok=byte49 (160/170)
counter=19, low
message1 not ok=byte6 (82/51)
message1 not ok=byte7 (211/43)
message1 not ok=byte8 (53/84)
message1 not ok=byte9 (51/205)
message1 not ok=byte13 (82/83)
message1 not ok=byte14 (171/83)
message2 not ok=byte17 (154/89)
message2 not ok=byte18 (102/154)
message2 not ok=byte19 (149/153)
message2 not ok=byte20 (165/170)
message2 not ok=byte21 (169/105)
message2 not ok=byte42 (89/90)
message2 not ok=byte43 (106/90)
message2 not ok=byte49 (160/170)
counter=19, low
message1 not ok=byte6 (82/51)
message1 not ok=byte7 (211/43)
message1 not ok=byte8 (53/84)
message1 not ok=byte9 (51/205)
message1 not ok=byte13 (82/83)
message1 not ok=byte14 (171/83)
message2 not ok=byte17 (154/89)
message2 not ok=byte18 (102/154)
message2 not ok=byte19 (149/153)
message2 not ok=byte20 (165/170)
message2 not ok=byte21 (169/105)
message2 not ok=byte42 (89/90)
message2 not ok=byte43 (106/90)
message2 not ok=byte49 (160/170)
counter=19, low

[ Voor 41% gewijzigd door rorie op 14-01-2017 14:08 ]

[Pixelmagic]

rorie schreef op zaterdag 14 januari 2017 @ 13:59:
Na een avondje solderen en testen wil het maar niet werken, mijn Itho geeft geen reactie, iemand met wat tips?

Iemand dezelfde ervaring dat zijn Itho bij een join op high gaat?

Als ik een join doe dan gaat hij inderdaad wat harder draaien voor een korte tijd, naar mijn gevoel niet op hoog maar iets in de midden. Dat is volgens de handleiding het teken dat de join succesvol was.

[rorie]

Oke, het werkt dus blijkbaar wel met de orginele versie https://github.com/supers...oFanRFT/IthoEcoFanRFT.ino. Waarom deze versie wel werkt is mij niet helemaal duidelijk, waarschijnlijk is de C++ library net even anders hier?

[racquemis]

Inmiddels wat zitten spelen met de logic analyzer op m'n esp8266 c1101 opstelling (weet aan de praat gekregen)
Kan de commando's message1 en message 2 van het low commando onderscheiden in de gegevens hoop. Wat wel vreemd is dat ik voor de eerste byte van message2 i.p.v een 1 continu 102 registreer.
Morgen aan de analyzer op de remote zetten, hopelijk komt er wat nuttigs uit voor de niet thuis functie

[racquemis]

Eerste update over het uitlezen remote:

Vandaag een opstelling gemaakt om de SPI communicatie van mijn remote uit te lezen.
Met de datasheet van de MEGA169PV erbij gekeken waar de signalen voor SCK, MOSI, MISO en CS zaten en natuurlijk ook de GND.
MISO blijkt compleet niet aangesloten zijn, voor de overige signalen zijn er mooie testeilandjes op de printplaat ruim genoeg om wat draden aan te solderen.
Het eindresultaat:



Na de draden aangesloten te hebben op de logic analyzer kwam de data al direct erg betrouwbaar binnen, meerdere keren op dezelfde drukken levert hetzelfde resultaat op.
Wat direct opvalt is dat deze remote met elke druk op de knop 6x het commando verstuurt. waar bij elke keer opnieuw alle configuratie registers geschreven worden (beetje inefficiënt)



Het commando heb ik nog niet kunnen vinden. geen van de markers die het begin of einde van een commando aanduiden heb ik kunnen vinden dus deze remote doet iets anders.
De ontvangen data is echter wel valide:
Het eerste SPI commando dat word gegeven is 0x30 – Reset CC1101
Gevolgd door:
- IOCFG0 = 0x2E
- FREQ2 = 0x21
- FREQ1 = 0x65
- FREQ0 = 0x6A
Volgens RFStudio komen de waarden voor FREQ2, FREQ1, FREQ0 overeen met een base frequency van 868.299866 Mhz

Later meer.

[sjimmie]

Goed bezig! Kijk vooral ff goed hoe Rogier het destijds aanpakte: http://www.progz.nl/blog/...-itho-cve-eco-rft-part-1/
Beter goed afgekeken dan iets verkeerd bedacht.

[edjeed]

Het commando heb ik nog niet kunnen vinden. geen van de markers die het begin of einde van een commando aanduiden heb ik kunnen vinden dus deze remote doet iets anders.
De ontvangen data is echter wel valide:
Het eerste SPI commando dat word gegeven is 0x30 – Reset CC1101
Gevolgd door:
- IOCFG0 = 0x2E
- FREQ2 = 0x21
- FREQ1 = 0x65
- FREQ0 = 0x6A
Volgens RFStudio komen de waarden voor FREQ2, FREQ1, FREQ0 overeen met een base frequency van 868.299866 Mhz

Later meer.

Eerst worden er initiële waardes gestuurd naar de CC1101, daarna wordt de CC1101 in IDLE mode gezet, pas daarna worden de configuraties voor send/receive en message1/message2 naar de CC1101 gestuurd.

MISO wordt wel gebruikt, maar als clock signaal voor het versturen van data (message1 en message2). even uit mijn hoofd SPI ==> MISO=clock, CSN = inverted CSN, data = GDO0. Als je SPI mode gebruikt is makkelijker dan de parallel mode die in de blog staat.

Zoals eerder vermeld ben ik bezig geweest met het aanpassen van het BW filter voor het ontvangen van data, maar helaas nog zonder succes.

Ps. de data die ik heb gemeten van de transmitter met een logic analyzer komt overeen met de blog en dus ook de code....


Pffff.... Eindelijk heb ik nu alles goed werkend, hier mijn aangepaste receive Code (onderdeel van IthoCC1101.cpp)

C++:

 

void IthoCC1101::initReceive()
{
    /*
    Configuration reverse engineered from RFT print.
    
    Base frequency      868.299866MHz
    Channel             0
    Channel spacing     199.951172kHz
    Carrier frequency   868.299866MHz
    Xtal frequency      26.000000MHz
    Data rate           38.3835kBaud
    RX filter BW        325.000000kHz
    Manchester          disabled
    Modulation          2-FSK
    Deviation           50.781250kHz
    TX power            0x6F,0x26,0x2E,0x7F,0x8A,0x84,0xCA,0xC4
    PA ramping          enabled
    Whitening           disabled
    */  
    writeCommand(CC1101_SRES);

    writeRegister(CC1101_TEST0 ,0x09);
    writeRegister(CC1101_FSCAL2 ,0x00);
    
    //0x6F,0x26,0x2E,0x7F,0x8A,0x84,0xCA,0xC4
    writeBurstRegister(CC1101_PATABLE | CC1101_WRITE_BURST, (uint8_t*)ithoPaTableReceive, 8);
    
    writeCommand(CC1101_SCAL);

    //wait for calibration to finish
    while ((readRegisterWithSyncProblem(CC1101_MARCSTATE, CC1101_STATUS_REGISTER)) != CC1101_MARCSTATE_IDLE) yield();

    writeRegister(CC1101_FSCAL2 ,0x00);
    writeRegister(CC1101_MCSM0 ,0x18);          //no auto calibrate
    writeRegister(CC1101_FREQ2 ,0x21);
    writeRegister(CC1101_FREQ1 ,0x65);
    writeRegister(CC1101_FREQ0 ,0x6A);
    writeRegister(CC1101_IOCFG0 ,0x2E);         //High impedance (3-state)
    writeRegister(CC1101_IOCFG2 ,0x2E);         //High impedance (3-state)
    writeRegister(CC1101_FSCTRL1 ,0x06);
    writeRegister(CC1101_FSCTRL0 ,0x00);
    writeRegister(CC1101_MDMCFG4 ,0xE8);
    writeRegister(CC1101_MDMCFG3 ,0x83);
    writeRegister(CC1101_MDMCFG2 ,0x00);        //Enable digital DC blocking filter before demodulator, 2-FSK, Disable Manchester encoding/decoding, No preamble/sync 
    writeRegister(CC1101_MDMCFG1 ,0x22);        //Disable FEC
    writeRegister(CC1101_MDMCFG0 ,0xF8);
    writeRegister(CC1101_CHANNR ,0x00);
    writeRegister(CC1101_DEVIATN ,0x50);
    writeRegister(CC1101_FREND1 ,0x56);
    writeRegister(CC1101_FREND0 ,0x17);
    writeRegister(CC1101_MCSM0 ,0x18);          //no auto calibrate
    writeRegister(CC1101_FOCCFG ,0x16);
    writeRegister(CC1101_BSCFG ,0x6C);
    // GAIN
    writeRegister(CC1101_AGCCTRL2 ,0x43);
    writeRegister(CC1101_AGCCTRL1 ,0x40);
    writeRegister(CC1101_AGCCTRL0 ,0x91);

    writeRegister(CC1101_FSCAL3 ,0xE9);
    writeRegister(CC1101_FSCAL2 ,0x2A);
    writeRegister(CC1101_FSCAL1 ,0x00);
    writeRegister(CC1101_FSCAL0 ,0x1F);
    
    writeRegister(CC1101_FSTEST ,0x59);
    writeRegister(CC1101_TEST2 ,0x81);
    writeRegister(CC1101_TEST1 ,0x35);
    writeRegister(CC1101_TEST0 ,0x0B);
    writeRegister(CC1101_PKTCTRL1 ,0x04);       //No address check, Append two bytes with status RSSI/LQI/CRC OK, 
    writeRegister(CC1101_PKTCTRL0 ,0x32);       //Infinite packet length mode, CRC disabled for TX and RX, No data whitening, Asynchronous serial mode, Data in on GDO0 and data out on either of the GDOx pins 
    writeRegister(CC1101_ADDR ,0x00);
    writeRegister(CC1101_PKTLEN ,0xFF);
    writeRegister(CC1101_TEST0 ,0x09);
    //writeRegister(CC1101_FSCAL2 ,0x00);

    writeCommand(CC1101_SCAL);

    //wait for calibration to finish
    while ((readRegisterWithSyncProblem(CC1101_MARCSTATE, CC1101_STATUS_REGISTER)) != CC1101_MARCSTATE_IDLE) yield();

    writeRegister(CC1101_MCSM0 ,0x18);          //no auto calibrate
    
    writeCommand(CC1101_SIDLE);
    writeCommand(CC1101_SIDLE);
    
    writeRegister(CC1101_MDMCFG2 ,0x00);        //Enable digital DC blocking filter before demodulator, 2-FSK, Disable Manchester encoding/decoding, No preamble/sync 
    writeRegister(CC1101_IOCFG0 ,0x0D);         //Serial Data Output. Used for asynchronous serial mode.

    writeCommand(CC1101_SRX);
    
    while ((readRegisterWithSyncProblem(CC1101_MARCSTATE, CC1101_STATUS_REGISTER)) != CC1101_MARCSTATE_RX) yield();
    
    initReceiveMessage1();
}

void IthoCC1101::initReceiveMessage1()
{
    uint8_t marcState;
    
    writeCommand(CC1101_SIDLE); //idle
    
    //set datarate
    writeRegister(CC1101_MDMCFG4 ,0xE8);
    writeRegister(CC1101_MDMCFG3 ,0x43);
    writeRegister(CC1101_DEVIATN ,0x40);
        
    //set fifo mode with fixed packet length and sync bytes
    writeRegister(CC1101_PKTLEN , 15);      //15 bytes message (sync at beginning of message is removed by CC1101)
    writeRegister(CC1101_PKTCTRL0 ,0x00);
    writeRegister(CC1101_SYNC1 ,170);       //message1 byte2
    writeRegister(CC1101_SYNC0 ,173);       //message1 byte3
    writeRegister(CC1101_MDMCFG2 ,0x02);
    writeRegister(CC1101_PKTCTRL1 ,0x00);   
    
    writeCommand(CC1101_SRX);               //switch to RX state

    // Check that the RX state has been entered
    while (((marcState = readRegisterWithSyncProblem(CC1101_MARCSTATE, CC1101_STATUS_REGISTER)) & CC1101_BITS_MARCSTATE) != CC1101_MARCSTATE_RX)
    {
        if (marcState == CC1101_MARCSTATE_RXFIFO_OVERFLOW) // RX_OVERFLOW
            writeCommand(CC1101_SFRX); //flush RX buffer
        yield();
    }
    
    receiveState = ExpectMessageStart;
}

void IthoCC1101::initReceiveMessage2(IthoCommand expectedCommand)
{
    uint8_t marcState;
    
    writeCommand(CC1101_SIDLE); //idle
    
    //set datarate  
    writeRegister(CC1101_MDMCFG4 ,0x5A);
    writeRegister(CC1101_MDMCFG3 ,0x83);
    writeRegister(CC1101_DEVIATN ,0x50);
    
    //set packet length based on expected message
    switch (expectedCommand)
    {
        case IthoJoin:
            writeRegister(CC1101_PKTLEN ,64);
            receiveState = ExpectJoinCommand;
            break;
            
        case IthoLeave:
            writeRegister(CC1101_PKTLEN ,57);
            receiveState = ExpectLeaveCommand;
            break;                  
            
        default:
            writeRegister(CC1101_PKTLEN ,42);           //42 bytes message (sync at beginning of message is removed by CC1101)
            receiveState = ExpectNormalCommand;
            break;
    }
    
    //set fifo mode with fixed packet length and sync bytes
    writeRegister(CC1101_PKTCTRL0 ,0x00);
    writeRegister(CC1101_SYNC1 ,170);           //message2 byte6
    writeRegister(CC1101_SYNC0 ,171);           //message2 byte7
    writeRegister(CC1101_MDMCFG2 ,0x02);
    writeRegister(CC1101_PKTCTRL1 ,0x00);   
    
    writeCommand(CC1101_SRX); //switch to RX state

    // Check that the RX state has been entered
    while (((marcState = readRegisterWithSyncProblem(CC1101_MARCSTATE, CC1101_STATUS_REGISTER)) & CC1101_BITS_MARCSTATE) != CC1101_MARCSTATE_RX)
    {
        if (marcState == CC1101_MARCSTATE_RXFIFO_OVERFLOW) // RX_OVERFLOW
            writeCommand(CC1101_SFRX); //flush RX buffer
        yield();
    }
}

[ Voor 71% gewijzigd door edjeed op 16-01-2017 12:14 . Reden: Receive werkt ;-) ]

[racquemis]

Mijn logic analyzer werd gistermiddag niet meer herkend in windows. Na een paar uur stoeien weer aan de praat gekregen en de niet-thuis code kunnen uitlezen:

Dit is dat er verzonden word:
Message 1: 170 170 170 172 173 45 44 203 84 171 85 53 84 204 205 84 170 171 85 77
Message 2: 170 170 170 170 170 170 170 171 254 0 179 42 171 42 149 154 101 90 85 105 169 166 169 166 149 170 102 89 150 170 165 101 90 150 85 149 101 90 86 85 150 105 153 90 172 170 170 170 170 170 7

jvdmast, kan je hier wat mee om het niet-thuis commando in de library te verwerken?

[edjeed]

Nog last van een aantal "unknown" messages, opgelost door :

C++:

void IthoCC1101::initReceiveMessage2(IthoCommand expectedCommand)
{
    uint8_t marcState;
    
    writeCommand(CC1101_SIDLE); //idle
    
    //set datarate  
    writeRegister(CC1101_MDMCFG4 ,0x9A);
    writeRegister(CC1101_MDMCFG3 ,0x83);
    writeRegister(CC1101_DEVIATN ,0x50);

[sjimmie]

edjeed schreef op maandag 16 januari 2017 @ 09:14:
[...]
Pffff.... Eindelijk heb ik nu alles goed werkend, hier mijn aangepaste receive Code (onderdeel van IthoCC1101.cpp)

Kan je aangeven wat er veranderd is? Dan kan ik makkelijker nagaan of dat mee te nemen is in een update op mijn (supersjimmie) github versie.
(dan graag incl je andere post)

[sjimmie]

racquemis schreef op maandag 16 januari 2017 @ 12:20:
Mijn logic analyzer werd gistermiddag niet meer herkend in windows. Na een paar uur stoeien weer aan de praat gekregen en de niet-thuis code kunnen uitlezen:

Dit is dat er verzonden word:
Message 1: 170 170 170 172 173 45 44 203 84 171 85 53 84 204 205 84 170 171 85 77
Message 2: 170 170 170 170 170 170 170 171 254 0 179 42 171 42 149 154 101 90 85 105 169 166 169 166 149 170 102 89 150 170 165 101 90 150 85 149 101 90 86 85 150 105 153 90 172 170 170 170 170 170 7

jvdmast, kan je hier wat mee om het niet-thuis commando in de library te verwerken?

Zekers!
Ik werk momenteel met een variant die alleen nog message2 stuurt omdat mijn itho daarnaar luistert, en dan zou een "niet thuis" er zo uit gaan zien:

code:

const uint8_t ithoMessage2AwayCommandBytes[]  = {6,89,150,170,165,101,90,150,85,149,101,90, 86, 85,150};

Wat voor mij eigenlijk best een beetje frusterend was, want een hele poos geleden had ik met een trial and error methode BIJNA hetzelde, ik zat er maar 1 byte naast, en binnen dat byte dan zelf maar 1 BIT!:

code:

const uint8_t ithoMessage2AwayCommandBytes[]  = {6,89,150,170,165,101,90,150,85,149,101,90,102, 85,150};

Mijn 102 moest 86 zijn en dat is precies 1 bit verschil.......

[sjimmie]

Helaas, ofwel ik mis iets ofwel mijn fan reageert er toch anders op.
De fan gaat, net als bij eerdere pogingen, vrijwel helemaal naar nul en iedere pakweg 15 sec gaat hij heel even naar een lage snelheid. Dat levert telkens een raar geluid op van kort opspinnen en weer stoppen.
EDIT: mijn fan blijkt er helemaal (nog) niet op te reageren. Dat zou met onderstaande te maken kunnen hebben, of we missen nog iets anders.

In de IthoCommand.h file zit

code:

typedef enum IthoCommand

Daar is nog niet bekend wat de waarde voor de niet-thuis zou moeten zijn. Helaas is die ook niet zomaar met 1 packet te achterhalen.
racquemis: denk je dat het zou lukken om ee reeks te verzamelen van meerdere malen op de knop drukken?
Ik weet niet zeker of ik er dan uit ga komen, want het zijn lastige berekeningen waavan al eens is gebleken dat ze weer per remote iets onderling verschillen... (dus de reverse-berekening van jouw byte-reeksen zouden dan anders kunnen zijn dan die van de remote die we in de huidige code gebruiken)

[ Voor 7% gewijzigd door sjimmie op 16-01-2017 21:52 ]

[edjeed]

sjimmie schreef op maandag 16 januari 2017 @ 18:19:
[...]

Kan je aangeven wat er veranderd is? Dan kan ik makkelijker nagaan of dat mee te nemen is in een update op mijn (supersjimmie) github versie.
(dan graag incl je andere post)

Heb even een fork gemaakt van je githubrepo, zie voor veranderingen de laatste commit...

https://github.com/edjeed/IthoEcoFanRFT

[racquemis]

Jvdmast, ik ga ermee aan de slag.
Het is wel een vreemde modus waar die bij je in terecht komt. Is de remote die de.library gebruikt toevallig een remote met normaal timer functie? Lijkt alsof elke remote andere instructielijsten heeft.
Zou interessant zijn om exact het interval tussen het upspinnen te bepalen. Misschien dat we dan het commando kunnen ontrafelen en nog meer controle krijgen over onze itho's

Morgen bouw ik even een script om makkelijker de data uit de ruwe analyzer gegevens om te zetten naar het volledige Message1 en Message2 commando. Dan kan ik zonder werk zoveel gegevens aanleveren als je wilt.

[sjimmie]

racquemis schreef op maandag 16 januari 2017 @ 21:55:
Jvdmast, ik ga ermee aan de slag.
Het is wel een vreemde modus waar die bij je in terecht komt. Is de remote die de.library gebruikt toevallig een remote met normaal timer functie? Lijkt alsof elke remote andere instructielijsten heeft.
Zou interessant zijn om exact het interval tussen het upspinnen te bepalen. Misschien dat we dan het commando kunnen ontrafelen en nog meer controle krijgen over onze itho's

Morgen bouw ik even een script om makkelijker de data uit de ruwe analyzer gegevens om te zetten naar het volledige Message1 en Message2 commando. Dan kan ik zonder werk zoveel gegevens aanleveren als je wilt.

Ik heb mijn vorige post aangepast, bijkt dat dat spinnen niet zo was (foutje van mij, verkeerde code gebruikt) en mijn fan verandert vooralsnog helemaal niet bij de niet-thuis code.
Ik heb inderdaad de remote met de timer en de originele code was ook op zo'n remote gebaseerd. Maar omdat de low/medium/full gewoon overeenkomen zal de timer en de niet-thuis ook onderling uitwisselbaar zijn. Het enige probleem zit in de berekeningen rondom de functies calculateMessage2Byte41() en calculateMessage2Byte42. Daar was al eens gebleken dat die functies niet op iedere remote tot hetzelfde resultaat leiden.

[edjeed]

racquemis schreef op maandag 16 januari 2017 @ 21:55:
Jvdmast, ik ga ermee aan de slag.
Het is wel een vreemde modus waar die bij je in terecht komt. Is de remote die de.library gebruikt toevallig een remote met normaal timer functie? Lijkt alsof elke remote andere instructielijsten heeft.
Zou interessant zijn om exact het interval tussen het upspinnen te bepalen. Misschien dat we dan het commando kunnen ontrafelen en nog meer controle krijgen over onze itho's

Morgen bouw ik even een script om makkelijker de data uit de ruwe analyzer gegevens om te zetten naar het volledige Message1 en Message2 commando. Dan kan ik zonder werk zoveel gegevens aanleveren als je wilt.

Gebruik de SPI modus van je Logic analyser voor Message1 en Message2 met de volgende pinout:

CLOCK == MISO pin
ChipSelect = inverted CSN pin (dus hoog-actief)
MOSI = GDO0 pin

Dan heb je alleen de messages en heb je geen script nodig :-)

[ Voor 0% gewijzigd door edjeed op 16-01-2017 23:04 . Reden: MISO aangepast naar MOSI ]

[racquemis]

Oke, ik gebruikte nu de simple parallel zoals ook de blogpost werd gedaan, maar blijkbaar kan het dus makkelijker. Ik probeer het morgen even opnieuw. Kan namelijk altijd dat ik nog ergens een foutje heb gemaakt met de byte reek die ik gegeven heb,

[ Voor 37% gewijzigd door racquemis op 16-01-2017 22:14 ]

[Igor Markovic]

Goedenavond,

Ik zit met veel interesse dit draadje te lezen. Ik ben zelf een software ontwikkelaar en heb in het verleden veel gehobbyd met eigen printjes maken en aansturen, maar dat was zo een 20 jaar terug. Nu ben ik me sinds kort maar weer gaan verdiepen in dit mooie wereldje, want er is tegenwoordig veel moois te vinden! Ik heb in mijn huis veel verschillende soorten RF apparatuur waaronder een Itho Ecofan 2HE! Dus mooi projectje om mee verder te gaan (na wat KAKU testjes te hebben gedaan).

Ik heb zelf momenteel een Arduino Uno met een el cheapo 433 Mhz tranceiver liggen (geen TI CC1101 oid). Alle gevonden Itho source code is voor een CC1101 tranceiver geschreven als ik het goed zie. Dus het lijkt mij dat mijn huidige tranceiver hier niet mee zal werken toch?

Aangezien een Arduino Uno 5V gebruikt op zijn pinnen en hij ook geen Wifi out of the box heeft zit ik te denken om over te stappen op een ESP8266 en nu vroeg ik mij het volgende af. Ik vind the Adafruit Feather Huzzah wel erg handig aangezien er ook een Adafruit FeatherWing is met een 868 MHz tranceiver die daar gelijk op past (en er gelijk een SMA connector op kan), maar nu vroeg ik mij af hoe lastig het is om de bestande code hiermee compatible te maken?

Indien dat lastig is, dan zal ik gewoon de CC1101 aansluiten op de Adafruit of NodeMcu die ik dan ga aanschaffen.

[sjimmie]

Kort antwoord: koop voor totaal 5 euro een 868MHz cc1101 en een nodemcu bij een Chinese webshop en bespraar jezelf een hoop gedoe.

[ThinkPad]

Hoe is het bereik eigenlijk met zo'n CC1101?
Kan ik CC1101 + ESP8266 in meterkast plaatsen en dan de ventilatiebox op zolder bereiken?

[Ierlandfan]

Wat maakt de CC1101 zo uniek en waarom kunnen we geen (insert-random-868mhz-transceiver) gebruiken?

[racquemis]

ThinkPadd schreef op dinsdag 17 januari 2017 @ 22:17:
Hoe is het bereik eigenlijk met zo'n CC1101?
Kan ik CC1101 + ESP8266 in meterkast plaatsen en dan de ventilatiebox op zolder bereiken?

Ja dit moet lukken, ik kan met de cc1101 met standaard antenne gewoon vanaf benden m'n itho op zolder sturen. Hij reageert direct. Nog geen haperingen erin gezien. Het ligt er misschien ook even beetje aan hoe goed de antenne gesoldeerd Is.

[racquemis]

Ierlandfan schreef op dinsdag 17 januari 2017 @ 22:46:
Wat maakt de CC1101 zo uniek en waarom kunnen we geen (insert-random-868mhz-transceiver) gebruiken?

Het kan wel echter ben je nooit zo goedkoop uit als met de cc1101 en zal je zelf de library moeten aanpassen om te werken met een andere transceiver.

[ThinkPad]

racquemis schreef op woensdag 18 januari 2017 @ 06:07:
[...]


Ja dit moet lukken, ik kan met de cc1101 met standaard antenne gewoon vanaf benden m'n itho op zolder sturen. Hij reageert direct. Nog geen haperingen erin gezien. Het ligt er misschien ook even beetje aan hoe goed de antenne gesoldeerd Is.

Bedankt, misschien toch maar eens over nadenken dan, ipv de oplossing met relais die ik eerst voor ogen had.

Hoe is de betrouwbaarheid schat je? Bij KlikAanKlikUit spul op 433Mhz wil het nog wel eens gebeuren dat een commando niet aankomt bij de ontvanger. Is het hier 10 uit 10 of valt er hier ook wel eens een commando weg? Of is dat een kwestie van aantal retries verhogen?

P.S. Misschien nog leuk voor de mensen hier, voor ~€22 haal je een CO₂-sensor uit China, die knup je aan een ESP8266 en dan kun je eenvoudig het CO₂-niveau in je woning uitlezen. Samen met zo'n CC1101-transmitter kun je dan mooi je ventilatie gaan aansturen op basis van de luchtkwaliteit en heb je een oplossing gemaakt waar je bij Itho zelf honderden euro's voor moet betalen.

[ Voor 22% gewijzigd door ThinkPad op 18-01-2017 08:47 ]

[sjimmie]

Ierlandfan schreef op dinsdag 17 januari 2017 @ 22:46:
Wat maakt de CC1101 zo uniek en waarom kunnen we geen (insert-random-868mhz-transceiver) gebruiken?

Daar is niets unieks aan.
Maar dit hele concept is gebaseerd op de originele remotes, die hebben een atmel processor en een intel CC1150 aan boord.

Oorspronkelijk is Rogier (http://www.progz.nl/blog/) begonnen met een cc1150 en een 3.3V versie arduino. Een mede-ontwikkelaar werkte weer met een andere atmel processor bordje. Die cc1150 is later vervangen door een cc1101 omdat de cc1150 alleen kan zenden (de cc1101 kan dus ook ontvangen). De arduino is vervangen door een esp8266 want die is handiger als je ook een webservertje wilt gebruiken.

Omdat we uiteindelijk ook weten wat er voor signalen door de ether gaan, ben je helemaal vrij om op een andere manier iets te bouwen wat hetzelfde doet. Maar dit werkt, dus voor de meeste mensen geldt dat dit een stuk makkelijker is dan met andere hardware opnieuw beginnen. En omdat de gebruikte hardware geen dr*l kost is er ook weinig reden om het met iets anders te gaan doen.

[racquemis]

@ThinkPad
De betrouwbaarheid? ik kan enkel zeg dat ik tot op heden nog geen gemist commando heb gehad. Als het goed is word het commando door de library reeds 3 maal verstuurd om de kans te vergroten dat het bericht opgepikt word. Je kan natuurlijk ook een z-wave energiemeter aan de Itho hangen en zo automatisch of binnen een gestelde tijd na het commando de itho harder gaat draaien, zo niet dan het commando opnieuw sturen en weer wachten.

[sjimmie]

ThinkPadd schreef op woensdag 18 januari 2017 @ 08:13:
[...]

Bedankt, misschien toch maar eens over nadenken dan, ipv de oplossing met relais die ik eerst voor ogen had.

Hoe is de betrouwbaarheid schat je? Bij KlikAanKlikUit spul op 433Mhz wil het nog wel eens gebeuren dat een commando niet aankomt bij de ontvanger. Is het hier 10 uit 10 of valt er hier ook wel eens een commando weg? Of is dat een kwestie van aantal retries verhogen?

P.S. Misschien nog leuk voor de mensen hier, voor ~€22 haal je een CO₂-sensor uit China, die knup je aan een ESP8266 en dan kun je eenvoudig het CO₂-niveau in je woning uitlezen. Samen met zo'n CC1101-transmitter kun je dan mooi je ventilatie gaan aansturen op basis van de luchtkwaliteit.

Zowel de originele remote als de variant hier stuurt de codes 3 keer. Hoe groot is de kans... Tsja, als ik onze zoon 3x roep dat we gaan eten is de kans groot dat hij het hoort, maar heel soms is 3x nog niet genoeg.
Natuurlijk puur afhankelijk van de de afstand en de obstakels, zo simpel is het.
Ik heb de cc1101 beneden en de fan op zolder met 2 betonnen vloeren en ik heb nooit iets gemist. En de normale remote hangt op de 1e verdieping in meestal ontvangt mijn cc1101 minstens 2 van de 3 verzonden pakketjes (ook die originele remote stuurt alles 3 keer).

Wat betreft CO₂, ik doe dat met een MQ135 van 1,50.
Niet nauwkeurig maar goed genoeg om de 3 snelheden van de itho aan te sturen.

[japie101]

ThinkPadd schreef op dinsdag 17 januari 2017 @ 22:17:
Hoe is het bereik eigenlijk met zo'n CC1101?
Kan ik CC1101 + ESP8266 in meterkast plaatsen en dan de ventilatiebox op zolder bereiken?

Ik kan inderdaad ook bevestigen dat de transmitter op de keukentafel prima functioneert op de Itho die op zolder staat. Dit doe ik gewoon met de kleine antenne die met de CC1101 meegeleverd wordt.
Gaat bij mij door 2 x betonvloer (nieuwbouwhuis).

[racquemis]

suggestie van edjeed werkte hier niet goed. Krijg het ook even niet voor elkaar om de ruwe data automatisch te verwerken naar de bruikbare codes. Handmatig kost tonnen tijd die ik op het moment niet heb.
Daarom onderstaand een link naar de ruwe data van 20x op de niet thuis knop drukken.

csv
http://ul.to/hfgw7nd0
logic analyzer:
http://ul.to/97cjzesf

[ Voor 6% gewijzigd door racquemis op 19-01-2017 19:58 ]

[edjeed]

racquemis schreef op donderdag 19 januari 2017 @ 19:37:
suggestie van edjeed werkte hier niet goed. Krijg het ook even niet voor elkaar om de ruwe data automatisch te verwerken naar de bruikbare codes. Handmatig kost tonnen tijd die ik op het moment niet heb.
Daarom onderstaand een link naar de ruwe data van 20x op de niet thuis knop drukken.

csv
http://ul.to/hfgw7nd0
logic analyzer:
http://ul.to/97cjzesf

Kan je omschrijven hoe je het hebt geprobeerd via SPI?

[racquemis]

Precies zoals jij het had in je post, meer kan ik er niet van maken.
Maar het is al gelukt via een klein script:

De resultaten van 15 keer op de knop drukken (incl repeats) - Gesorteerd
http://pastebin.com/54Tpfa6D

[ Voor 6% gewijzigd door racquemis op 19-01-2017 22:25 ]

[edjeed]

https://i1.wp.com/www.pro...o-afstandbediening-v2.jpg

Voor de pinout....

https://i0.wp.com/www.pro...creenshot-3-one-block.png


Hier kan je zien dat MISO (in het eerste plaatje is dat SO) als klok signaal gebruikt wordt, SPI Enable (in het eertse plaatje CSn) als hoog-actief enable en GDIO0 (zoals in eerste plaatje) als data.
Zo heb ik de message-data kunnen uitlezen van mijn remote....

[racquemis]

ik heb hetzelfde resultaat als in de 2de adbeelding. dus klopt dus wel. het script automatiseert het samenvoegen van de laatste bit van elke regel.

[rorie]

Nu alles hier werkt ben ik mijn code wat aan het opschonen en kwam ik tot de volgende vragen, als je de sendRegister(); uit de setup weglaat kan je dan de rf.init() ook weglaten? Wat doet rf.init() eigenlijk, het resetten van alle registers?

Moet rf.initReceive() in de Loop() functie of kan deze ook naar de Setup, dus eenmalig worden uitgevoerd? Wat doet deze functie precies, ook het legen van de registers?

[edjeed]

rorie schreef op vrijdag 20 januari 2017 @ 09:35:
Nu alles hier werkt ben ik mijn code wat aan het opschonen en kwam ik tot de volgende vragen, als je de sendRegister(); uit de setup weglaat kan je dan de rf.init() ook weglaten? Wat doet rf.init() eigenlijk, het resetten van alle registers?

Moet rf.initReceive() in de Loop() functie of kan deze ook naar de Setup, dus eenmalig worden uitgevoerd? Wat doet deze functie precies, ook het legen van de registers?

rf.init reset de CC1101, dit moet dus in de setup blijven staan.

De rf.initReceive zet de cc1101 in receive mode voor het ontvangen van message1. Deze kan dus verplaatst worden naar de setup (na de rf.init natuurlijk )

Nadat een bericht is verstuurd moet de rf.initReceive weer worden aangeroepen om in de receive mode te komen voor het ontvangen van message1.

[rorie]

Bedankt voor je reactie, wat je zegt klinkt logisch. Initieel in de setup dus een rf.init() en daarna een rf.initReceive() waardoor de cc1101 geinitialiseerd word en daarna in de receive mode word gezet. Zodra er een rf.sendCommand() gestuurd is kan er geen data van externe remotes ontvangen worden tot dat de rf.initReceive() weer aangeroepen is.

Wat zou betekenen dat de code van incmve (https://github.com/incmve/Itho-WIFI-remote) niet werkt omdat daar enkel een rf.initReceive() in de setup word gedaan, zonder een rf.init() en na de setup ook geen rf.initReceive() meer.

[deklusjesman]

racquemis schreef op maandag 16 januari 2017 @ 12:20:
Mijn logic analyzer werd gistermiddag niet meer herkend in windows. Na een paar uur stoeien weer aan de praat gekregen en de niet-thuis code kunnen uitlezen:

Dit is dat er verzonden word:
Message 1: 170 170 170 172 173 45 44 203 84 171 85 53 84 204 205 84 170 171 85 77
Message 2: 170 170 170 170 170 170 170 171 254 0 179 42 171 42 149 154 101 90 85 105 169 166 169 166 149 170 102 89 150 170 165 101 90 150 85 149 101 90 86 85 150 105 153 90 172 170 170 170 170 170 7

jvdmast, kan je hier wat mee om het niet-thuis commando in de library te verwerken?

Je zou eigenlijk een reeks berichten moeten bekijken. Sommige bytes die afhankelijk zijn van de counter zijn ook afhankelijk van het commando.

Om het snel te achterhalen zou je counter=1 moeten opzoeken. Als je dan een aantal berichten verzameld totdat een bepaalde counter byte wisselt dan kan je afleiden hoeveel bytes uit die fixed arrays de data versprongen is. Of misschien dat er een geheel andere calculatie achter zit. Maar om dat te bepalen is een reeks berichten erg handig.

Ik heb destijds alle berichten (counter, afgeleide bytes, command) in een database gezet. In eerste instantie heb ik de remote gereverse engineerd, maar op een gegeven moment ben ik daarmee gestopt en heb toen de itho fan print zelf onderzocht. Daarna kon ik alle berichten zelf ontvangen en dus ook eenvoudig loggen om ze in de database te stoppen. Vandaar uit ben ik weer verder gegaan met de remote. Met alle verzamelde data kon ik uittesten of mijn calculaties werkten. De code heb ik eerst met visual studio geschreven (zonder atmega) omdat het alleen om het algoritme ging. Met één berichtje is dat bijna niet te doen, teveel trial and error.

Wat betreft het gebruik van de CC11xx. Dat was een handige keuze omdat itho die chip ook gebruikt. De reverse engineerde SPI commands konden daardoor direct op de testopstelling gebruikt worden.

[edjeed]

rorie schreef op vrijdag 20 januari 2017 @ 10:45:
Bedankt voor je reactie, wat je zegt klinkt logisch. Initieel in de setup dus een rf.init() en daarna een rf.initReceive() waardoor de cc1101 geinitialiseerd word en daarna in de receive mode word gezet. Zodra er een rf.sendCommand() gestuurd is kan er geen data van externe remotes ontvangen worden tot dat de rf.initReceive() weer aangeroepen is.

Wat zou betekenen dat de code van incmve (https://github.com/incmve/Itho-WIFI-remote) niet werkt omdat daar enkel een rf.initReceive() in de setup word gedaan, zonder een rf.init() en na de setup ook geen rf.initReceive() meer.

rf.init is nodig om ervoor te zorgen dat de initialisatie goed gaat na power up, als er pinnen zweven of (in)actief worden tijdens het opstarten van de ESP terwijl de CC1101 al actief is, kunnen er onvoorziene situaties ontstaan. het kan dus goed gaan, maar het is beter om de cc1101 te resetten nadat de ESP is opgestart.

Voor de rf.initReceive... Check de Issue op github

[sjimmie]

deklusjesman schreef op vrijdag 20 januari 2017 @ 10:51:
[...]

Je zou eigenlijk een reeks berichten moeten bekijken. Sommige bytes die afhankelijk zijn van de counter zijn ook afhankelijk van het commando.

In de basis is 1 reeks al vrijwel genoeg.
Daaruit is in ieder geval het vaste stuk te halen, dus het command.
Die heb ik eruit kunnen halen als const uint8_t ithoMessage2AwayCommandBytes[].

Logischerwijs had ik gehoopt dat het minieme verschil rondom de counter-berekeningen wel te gokken zou zijn. Want met wat we nu al kennen:

code:

    IthoLow = 35,   
    IthoMedium = 36,    
    IthoFull = 37,

Zou ik verwachten dat de Away stand iets van 34 zou moeten zijn (of in ieder geval iets in de buurt).
Het lijkt nu geen 34 te zijn, dus wil ik binnenkort wat omringende waardes bruut testen.

Daarbij ga ik er dan wel vanuit dat de "byte41 en verder" berekeningen, dus los van de waardes, voor de Away stand hetzelfde blijven.

[deklusjesman]

Ik heb vanochtend atmel studio geinstalleerd en alles weer aangesloten. Ik kan nog steeds commands zenden en de rft reageert er op. Het enige probleem is de soft uart, ik kan niks meer loggen over de serial poort. Ik heb een nieuwe laptop en geen vaste serial poort meer (op docking station). Ik vermoed dat het niet werkt met de usb-serial converter. Als dit nou werkend is dan had ik ook zo;n andere remote gekocht. Maar zonder log kan ik niet zoveel. Zal eens een andere oplossing verzinnen.

edit: pff, de baudrate heb ik ooit eens hoog gezet in de code. Had verder alles op 9600 laten staan. Heb het aan de gang gekregen.

Ik had ook ooit zo'n antenne van 18cm besteld en deze werkt voor het zenden in elk geval perfect. Had eerder een stukje draad van een paar cm eraan hangen.

[ Voor 22% gewijzigd door deklusjesman op 20-01-2017 14:11 ]

[remcoXP]

heeft iemand ervaring met: http://www.banggood.com/X...1095214.html?rmmds=search
?
het leek mij een mooi cameratje om in de keuken te plaatsen zodat ik kan zien wie er voor de deur zit.

dus een snapshot of via synology surveillance.. iemand die kan bevestigen dat dit een leuke koop is voor dit doeleinde ?

[sjimmie]

remcoXP schreef op vrijdag 20 januari 2017 @ 17:09:
heeft iemand ervaring met: http://www.banggood.com/X...1095214.html?rmmds=search
?
het leek mij een mooi cameratje om in de keuken te plaatsen zodat ik kan zien wie er voor de deur zit.

dus een snapshot of via synology surveillance.. iemand die kan bevestigen dat dit een leuke koop is voor dit doeleinde ?

Euhm, wil je dan je itho ecofan met die camera gaan bedienen?

[Templar]

sjimmie schreef op zondag 8 januari 2017 @ 19:02:
[...]

Partnum en version kunnen geen 255 zijn, dit wijst op geen communicatie.
En inderdaad zal de boel gewoon crashen als er geen communicatie is (er zit geen veilige controle in).

Oke, ben er achter. Had de zaak gewoon verkeerd aangesloten....
Krijg nu deze melding:

code:

CC1101_PARTNUM 0
CC1101_VERSION 20
CC1101_MARCSTATE 1
setup done
sending join...
send
sending join done.
join command sent
start

Oftewel, een goede hardware verbinding. Ik heb hier twee verschillende remotes liggen (een CC1150 en een Infineon TDK5110) maar hoe krijg ik ze gejoined? De 3 testCreateMessage() in het IthoCC1101.cpp bestand zijn 'geactiveerd'. Maar met het indrukken van de remote knoppen verschijnt er geen output in m'n serial monitor.

[deklusjesman]

Ik heb zo'n Duco C remote in huis met standby knop.

In mijn code op github zit een fout. Misschien dat jullie die al gevonden hebben. Message1 en message2 hebben ieder hun eigen "device id". In de oorspronkelijke code was er 1 device id. In één van de functies werden de bytes van het device id hardcoded weggeschreven. Hiervoor had ik natuurlijk de array met het id moeten gebruiken. Ik vermoed dat message1 nooit goed gewerkt heeft omdat ik het device id van message2 erin wegschreef.

Het command voor de standby was eenvoudig te achterhalen. Ik heb eerst de al bestaande commands gecontroleerd en het blijkt dat deze in message1 1 bit anders hebben staan ten opzichte van mijn andere remote.

In message2 krijg ik foutmeldingen in de log op enkele counter bytes. Na een aantal keer drukken kan ik zien dat statische arrays hetzelfde zijn, maar de calculatie iets aangepast moet worden. De data verloopt namelijk iets. Nu is dus de vraag hoe dit allemaal bepaald is. Ik vermoed dat een bit\byte in het "device id" hier invloed op heeft. Het probleem is dat ik met data van 2 remotes dit niet kan achterhalen. Ik heb daarvoor veel meer data nodig om te vergelijken.

Hetgeen waar ik naartoe wil is alle commands werkend in de software. Met hetgeen ik nu weet kan ik echter:
- remote met timerknop, alle commands werkend
- remote met standby, alle commands werkend (nog niet geimplementeerd)

Maar het zou natuurlijk interessant zijn om de standby command op de code van de remote met timerknop te gebruiken. Of andersom, de timer functie op de remote met de standbyknop.

Het lijkt me dat dit mogelijk moet zijn en dat hier een nog onbekende berekening achter zit.

Op dit moment heb ik de volgende verschillen:
- message1 byte13 en 14 (command byte) verschil van 1 bit
- message2, byte41,42,43 (counter bytes) verloop

De overige bytes zien er tot dusver allemaal goed uit. Ook de overige counter bytes. Vandaar dat ik vermoed dat er een berekening achter zit die data gebruikt uit het "device id". Want dat is het enige verschil tussen de remotes.

[racquemis]

Geen wonder dat ik zoveel moeite had om goede data te receiven:
Mijn remote heeft andere sync bytes dan gedefinieerd in de library van Jimmy
Wanneer ik in de InitReceive1 functie SYNC1 verander van 170 naar 172 krijg ik ineens correcte waarden binnen. Ik krijg nog geen melding dat een knop is ingedrukt maar dit is iig een begin.

Op m'n remote staat het volgende:
536-0024 1225 hs15/s10

[deklusjesman]

De message2 commands van de verschillende remotes zijn precies hetzelfde. Ik had in jouw waarden die je eerder gepost had die 172 al zien staan. Blijkbaar accepteert itho zowel 170 als 172, want ik heb bij beide remotes 170.

Ik heb inmiddels de berekeningen van de counter bytes aangepast op het standby command. De aanpassingen zijn in lijn met de berekeningen die er al waren. Het enige dat nogal afwijkt is de enum waarde van het standby command. Deze enum waarde wordt gebruikt in berekeningen. Ik ga straks even spelen met die enum waarde en kijken of de fan reageert. Wellicht dat die enum waarde (ontbrekende berekening) het verschil is tussen de remotes.

[racquemis]

Ik heb nog wat gegevens verzameld aangezien de byte arrays van Message1 overeenkomen met hetgeen in de library. Message2 is inderdaad identiek met wat verwacht. Tevens heb in de functie ValidMessageStart de 170 moeten veranderen in 171

code:

ithoMessage1FullCommandBytes[] = {0,213,85,50,181,84,170};
ithoMessage1MediumCommandBytes[] = {0,213,85,74,171,84,170}
ithoMessage1LowCommandBytes[] = {0,213,85,83,45,52,170}
ithoMessage1AwayCommandBytes[] = {1,53,84,204,205,84,170}

Wanneer ik op de niet-thuis knop druk krijg ik trouwens op mijn esp8266 een fatal exception ergens in of na de aanroep van TestCreateMessage

[ Voor 22% gewijzigd door racquemis op 21-01-2017 15:06 ]

[deklusjesman]

Ik heb de enum waardes voor de commands bepaald voor de Duco remote. Als ik dat vertaal naar de andere remote dan zou standby enum waarde 34 moeten krijgen. Maar de fan reageert er niet op.

Behalve de enum waarden die anders zijn op de duco remote moet ook de functie calculateMessageByte43 aangepast worden. Voor het low command heb ik dit gedaan. Op zich is het niet zoveel werk om die duco remote vanuit code volledig werkend te krijg. Het verschil zit hem erin dat er een klein beetje verloop is ten opzichte van de bestaande code. In die functie wordt de counter waarde aangepast. Voor de duco moet ie anders aangepast worden dan voor de rft remote.

Maarja, ik wil eigenlijk zien te achterhalen hoe het nou allemaal werkt. Ik denk dat er nog iets verborgen zit in het device id. Of misschien in de bytes van de join. De fan moet op één of andere manier te weten komen welke berekening gebruikt moet worden tijdens het parsen.

edit: het join bericht is voor beide remotes hetzelfde. De enum waarde voor de join is ook correct. Het is logisch dat beide remotes hetzelfde bericht gebruiken. De itho fan weet voor aanvang van het join bericht niet welke berekening toegepast moet worden, daarom is deze altijd hetzelfde. Dat betekent dat de afwijkingen in de berekeningen bepaald worden door het "device id".

[ Voor 16% gewijzigd door deklusjesman op 21-01-2017 17:29 ]

[remcoXP]

Oeps verkeerde topic jvdmast

[sjimmie]

Templer schreef op zaterdag 21 januari 2017 @ 12:09:
[...]
Oftewel, een goede hardware verbinding. Ik heb hier twee verschillende remotes liggen (een CC1150 en een Infineon TDK5110) maar hoe krijg ik ze gejoined? De 3 testCreateMessage() in het IthoCC1101.cpp bestand zijn 'geactiveerd'. Maar met het indrukken van de remote knoppen verschijnt er geen output in m'n serial monitor.

Een cc1150 kan sowieso niet ontvangen.
Het joinen werkt aan de itho kant hetzelfde als bij een gewone remote. Stekker eruit, stekker erin en binnen 1 minuut vanaf je cc1101/1150 een join command laten sturen.

[racquemis]

Oké, ik heb het voor elkaar gekregen dat m'n itho nu op het niet-thuis commando reageert.
Als enumwaarde heb ik 34 en vervolgens in de byte calculaties in alle switch case op de plek waar 'case IthoLow:' staat vermeld ook case IthoAway toegevoegd.

One Catch: Hij reageert enkel wanneer ik het niet-thuis commando voor een tweede keer geef.
Dus als ik eerst het low/medium/high commando geef en vervolgens het away commando doet mijn itho niks. Stuurt ik vervolgens het away commando nogmaals dan springt de Itho wel naar de niet-thuis stand.

Ik gebruik wel de commandbytes voor low/medium/full van mijn eigen remote. Weet niet of dat er wat mee te maken kan hebben dat het hier nu werkt?

[ Voor 11% gewijzigd door racquemis op 22-01-2017 12:54 ]

[Speedy-Andre]

Da's mooi, ik ga er ook eens mee beginnen nu ik lees dat het bereik goed is.
Zorgt de niet-thuis stand voor een extra laag toerental of gaat hij dan af en toe op low en uit?

[deklusjesman]

racquemis schreef op zondag 22 januari 2017 @ 12:52:
One Catch: Hij reageert enkel wanneer ik het niet-thuis commando voor een tweede keer geef.
Dus als ik eerst het low/medium/high commando geef en vervolgens het away commando doet mijn itho niks. Stuurt ik vervolgens het away commando nogmaals dan springt de Itho wel naar de niet-thuis stand.

Ik gebruik wel de commandbytes voor low/medium/full van mijn eigen remote. Weet niet of dat er wat mee te maken kan hebben dat het hier nu werkt?

In die byte43 functie heb ik onderstaande case voor de duco remote. Heb ik uitgerekend aan de hand van de ontvangen berichten. CreateTestMessage geeft geen fouten erop.
case standby:
counter += 8;
if (counter % 2 == 0) counter -= 1;
break;


Bij mijn duco remote zit het standby command op 251 ipv 34. Low op 252 ipv 35. Bij mij werkt command 34 niet op de normale rft remote.

Werken de timer commands bij jou nog op de duco remote?

[ Voor 4% gewijzigd door deklusjesman op 22-01-2017 13:47 ]

[racquemis]

Speedy-Andre schreef op zondag 22 januari 2017 @ 13:17:
Da's mooi, ik ga er ook eens mee beginnen nu ik lees dat het bereik goed is.
Zorgt de niet-thuis stand voor een extra laag toerental of gaat hij dan af en toe op low en uit?

Ja de Itho gaat ermee op ongeveer helft van het toerental van low lopen en blijft daarop lopen

[racquemis]

deklusjesman schreef op zondag 22 januari 2017 @ 13:43:
[...]


In die byte43 functie heb ik onderstaande case voor de duco remote. Heb ik uitgerekend aan de hand van de ontvangen berichten. CreateTestMessage geeft geen fouten erop.
case standby:
counter += 8;
if (counter % 2 == 0) counter -= 1;
break;


Bij mijn duco remote zit het standby command op 251 ipv 34. Low op 252 ipv 35. Bij mij werkt command 34 niet op de normale rft remote.

Werken de timer commands bij jou nog op de duco remote?

Ik gebruik in de software volgens mij gewoon de code voor de normale rft remote. (github Jimmy) De join/leave is onveranderd en de enum waarden ook. 34 werkt hier bij mij gewoon.

Ik heb byte43 aangepast met de code die je gegeven hebt, de Itho reageert er niet op. Dus weer teruggezet naar wat het was.

De Timer functie werkt hier gewoon. Op het issue met de away command na werkt alles nu perfect.

[ Voor 14% gewijzigd door racquemis op 22-01-2017 14:29 ]

[sjimmie]

racquemis schreef op zondag 22 januari 2017 @ 12:52:
Oké, ik heb het voor elkaar gekregen dat m'n itho nu op het niet-thuis commando reageert.
Als enumwaarde heb ik 34 en vervolgens in de byte calculaties in alle switch case op de plek waar 'case IthoLow:' staat vermeld ook case IthoAway toegevoegd.

One Catch: Hij reageert enkel wanneer ik het niet-thuis commando voor een tweede keer geef.
Dus als ik eerst het low/medium/high commando geef en vervolgens het away commando doet mijn itho niks. Stuurt ik vervolgens het away commando nogmaals dan springt de Itho wel naar de niet-thuis stand.

Ik gebruik wel de commandbytes voor low/medium/full van mijn eigen remote. Weet niet of dat er wat mee te maken kan hebben dat het hier nu werkt?

Mooi het zou dus wel moeten kunnen werken.
Dat je nog 2 keer de away moet aanroepen wijst op een detail foutje in de counterbytes (41-43). Klusjesman is daarmee bezig. Verwarrend dat dus het ene resultaat en het andere (klusjesman en racquemis) elkaar nog tegenspreken.

Oja, even terug riep je iets over een crash als je op je remote op de niet-thuis drukte? Dat zal wellicht komen omdat je dan nog niet overal in iedere case-switch de away hebt meegenomen.

Het is jammer dat ik momenteel alleen een tablet beschikbaar heb en dus niets aan de code kan veranderen of testen. Maar volgens mij zijn we met de resultaten tot nu toe al zo ver dat het helemaal werkt tegen de tid dat ik weer "mee kan doen".

[racquemis]

De crash is inmiddels verholpen, ik denk inderdaad door een vergeten case ergens. Ineens werkte het wel, geen idee wat ik precies ervoor veranderd heb.

Het verschil tussen klusjesman en mij zit wellicht in dat hij zijn remote bij de itho als de duco remote registreert via de join i.p.v. als de rft remote??

Ik zal binnenkort de code even delen zoals ik die nu gebruik. Ben dan benieuwd of anderen het ook werkend krijgen.

[deklusjesman]

Ik heb mijn code aangepast voor zowel de rft als duco remote en werkt perfect. Moet alleen de leave nog corrigeren voor de duco omdat er een paar bytes verkeerd berekend worden.

Heb vandaag ook voor het eerst getest wat die standby functie nu eigenlijk doet. Heb dit in eerste instantie via software gedaan (join getest). Later ook even met de remote zelf getest. Als je de potmeter van de laagste stand op zn laagst hebt staan dan doet de standby stand helemaal niets anders dan de low stand.

Ik heb alle functies aangepast om de counter bytes van de duco remote te berekenen (op leave na). Blijkbaar zijn er 2 (of meer?) varianten van remotes. Ik heb de berekeningen voor de commands in de 250 range werkend. De vraag is nu of er bij de 35 range iets veranderd is met de duco remote ten opzichte van de counter bytes van de gewone rft remote.

Ik zou ook wel willen weten hoe dit allemaal bepaald is. Het lijkt me dat er uit het device id een paar bits worden getrokken om de berekeningen aan te passen. Maargoed, ik denk dat je veel data moet hebben van verschillende remotes om dat makkelijk te kunnen achterhalen.

Ik zal straks nog eens proberen of die timer functies werken met de duco.

[deklusjesman]

racquemis schreef op zondag 22 januari 2017 @ 16:10:
Het verschil tussen klusjesman en mij zit wellicht in dat hij zijn remote bij de itho als de duco remote registreert via de join i.p.v. als de rft remote??

Dat klopt. Het is me nog niet gelukt die standby functie te gebruiken via een gejoinde rft remote.

edit: ik heb de standby nu ook werkend met de rft remote code. Dan kan eigenlijk mijn hele duco code er weer uit denk ik. Zal het nog eens goed testen of alle counter bytes goed zijn, is lastig te controleren omdat de berekening anders is dan met de duco remote.

edit: ik kom er nu achter dat zowel 34 als 251 werken als standby command. Alleen op verschillende momenten omdat de berekening van (ik gok) byte43 dan niet klopt.

edit:
de goede code moet zijn, werkt perfect hier:

case rft_standby:
counter -= 1;
if (counter % 2 == 0) counter -= 1;
break;

edit: er is ook een tegenhanger van standby, heb het commando beredeneerd en de enum is ook goed. Hij gaat hiermee op full power en maakt dan wel veel herrie. Dus in feite heb ik nu 5 standen.

[ Voor 57% gewijzigd door deklusjesman op 22-01-2017 18:10 ]

[sjimmie]

Haha ja nu je dat zegt van die tegenhanger als vol gas, er was eens een eerste poging waarbij iemand mijn code uitprobeerde met een gedeelte van de standby/away en daar ging zijn itho juist op volle toeren.

Zelf had ik op een gegeven moment een stand tussen away en low, hij ging (bijna?) helemaal uit en daarna iedere pakweg 15 sec heel even draaien. Dus er is vanalles mogelijk, maar niet alles is wenselijk.

Zodra ik weer een laptop heb met de arduino ide, alle libraries enzovoorts ga ik er snel weer mee aande gang! Nu jullie het al werkend hebben kriebelt hier nogal.

Wel goed om te weten dat de standby/away hetzelfde is als de low-potmeter minimaal. Want als je die al
minimaal hebt staan dan bereik je dus niets en lijkt het niet te werken...

[deklusjesman]

Ik zal later alles op github zetten. Wil eerst nog de aanpassingen die ik vanwege de duco remote had gemaakt eruit halen. Verder ga ik nog bekijken wat ik met message1 ga doen. Deze klopt niet bij alle commands. Maar voor de ontvangst is deze wel handig om de message buffer voor het 2e bericht in te kunnen stellen. Nu is dat niet zo van belang voor de werking, maar wel voor eventueel reverse engineeren in de toekomst.

De aanpassingen die nodig zijn staan hieronder. Ik heb alleen de veranderingen in de functies laten staan omdat het anders zoveel plakwerk wordt. Het inspringen van de code moeten jullie er zelf bij bedenken.

typedef enum IthoCommand
{
rft_standby = 34,
rft_fullpower = 38,
};

const uint8_t ithoMessage2PowerCommandBytes[] = {6,89,150,170,165,101,90,150,85,149,101,90,102,85,150};

const uint8_t ithoMessage2StandByCommandBytes[] = {6,89,150,170,165,101,90,150,85,149,101,90,86,85,150};

uint8_t IthoCC1101::calculateMessage2Byte41(uint8_t counter, IthoCommand command)
{
int var = 0;
uint8_t hi = 0;

switch (command)
{
default:
hi = 96;
var = 48 - command;
if (counter < var) counter = 74 - counter;
break;
}

return (hi | counterBytes41[((counter - var) % 64) / 16]);
}

uint8_t IthoCC1101::calculateMessage2Byte43(uint8_t counter, IthoCommand command)
{
switch (command)
{
case rft_fullpower:
counter += 3;
if (counter % 2 == 0) counter -= 1;
break;

case rft_standby:
counter -= 1;
if (counter % 2 == 0) counter -= 1;
break;
}
return counterBytes43[(counter % 16) / 2];
}

uint8_t* IthoCC1101::getMessage2CommandBytes(IthoCommand command)
{
switch (command)
{
case rft_fullpower:
return (uint8_t*)&ithoMessage2PowerCommandBytes[0];
case rft_standby:
return (uint8_t*)&ithoMessage2StandByCommandBytes[0];
}
}

[Templar]

sjimmie schreef op zondag 22 januari 2017 @ 11:56:
[...]

Een cc1150 kan sowieso niet ontvangen.
Het joinen werkt aan de itho kant hetzelfde als bij een gewone remote. Stekker eruit, stekker erin en binnen 1 minuut vanaf je cc1101/1150 een join command laten sturen.

Klein misverstand hier, had mijn situatie moeten beschrijven. Ik heb geen Itho systeem met RFT ontvanger maar alleen de CC1101/NodeMCU combinatie samen met de twee genoemde Itho RFT zenders.

Moeten de Itho RFT zenders joinen met de CC1101/NodeMCU of worden commando's van elke zender geaccepteerd?

[edjeed]

Templer schreef op zondag 22 januari 2017 @ 19:46:
[...]


Klein misverstand hier, had mijn situatie moeten beschrijven. Ik heb geen Itho systeem met RFT ontvanger maar alleen de CC1101/NodeMCU combinatie samen met de twee genoemde Itho RFT zenders.

Moeten de Itho RFT zenders joinen met de CC1101/NodeMCU of worden commando's van elke zender geaccepteerd?

De RFT zenders hoeven niet gejoined te zijn om data met de CC1101 te ontvangen

[ThinkPad]

deklusjesman schreef op zondag 22 januari 2017 @ 19:44:
Ik heb alleen de veranderingen in de functies laten staan omdat het anders zoveel plakwerk wordt. Het inspringen van de code moeten jullie er zelf bij bedenken.
[...]

offtopic:
Tip, gebruik de [code]test[/code] tags. Of zelfs met highlighting als [code=c++]test[/code]gebruikt.
Grote stukken code hier op het forum plakken is niet zo handig, een GitHub accountje of even op www.pastebin.com gooien is dan beter.

[deklusjesman]

ThinkPadd schreef op maandag 23 januari 2017 @ 10:08:
[...]

offtopic:
Tip, gebruik de [code]test[/code] tags. Of zelfs met highlighting als [code=c++]test[/code]gebruikt.
Grote stukken code hier op het forum plakken is niet zo handig, een GitHub accountje of even op www.pastebin.com gooien is dan beter.

Misschien is het dan handig om die [code] tag ook ergens kenbaar te maken. Als ik een nieuwe reactie type zie ik een berg smileys en een reeks andere tags, maar niks wat toepasbaar zou kunnen zijn voor een stuk code. Heb hier voor plaatsing nog naar gezocht. Op veel fora is er een tag waarmee je een stuk tekst kan in\uitklappen. Zoiets had ik wel als icoontje verwacht tijdens het invoeren. Ik ga er verder ook geen studie van maken als ik een keer iets post.

[edjeed]

deklusjesman schreef op maandag 23 januari 2017 @ 10:32:
[...]
Misschien is het dan handig om die [code] tag ook ergens kenbaar te maken. Als ik een nieuwe reactie type zie ik een berg smileys en een reeks andere tags, maar niks wat toepasbaar zou kunnen zijn voor een stuk code. Heb hier voor plaatsing nog naar gezocht. Op veel fora is er een tag waarmee je een stuk tekst kan in\uitklappen. Zoiets had ik wel als icoontje verwacht tijdens het invoeren. Ik ga er verder ook geen studie van maken als ik een keer iets post.

Voor alle tags....

Overzicht van UBB-codes

[deklusjesman]

Ik heb alle aanpassingen op github gezet (/Klusjesman/IthoEcoFanRFT).

Ik zal later nog eens bekijken of er ook een commando bestaat om de gehele fan uit te schakelen.

[rorie]

Oke, dus ik kan ook gewoon de RFT zender van de buurman ontvangen? Die heeft namelijk precies dezelfde opstelling en dat zou ook gelijk verklaren waarom mijn status af en toe op high staat en de Itho Eco fan op stand 1. Is er een mogelijkheid om het ID van de FR remote die het commando stuurde te achterhalen?

edjeed schreef op maandag 23 januari 2017 @ 09:55:
[...]


De RFT zenders hoeven niet gejoined te zijn om data met de CC1101 te ontvangen

[sjimmie]

rorie schreef op dinsdag 24 januari 2017 @ 08:40:
Oke, dus ik kan ook gewoon de RFT zender van de buurman ontvangen? Die heeft namelijk precies dezelfde opstelling en dat zou ook gelijk verklaren waarom mijn status af en toe op high staat en de Itho Eco fan op stand 1. Is er een mogelijkheid om het ID van de FR remote die het commando stuurde te achterhalen?


[...]

Ja om die reden heb ik er bij mijzelf wat extra code in gezet.
Daarmee check ik of het ontvangen ID wel het ID is van mijn remote.

[rorie]

Oke, die staat ook ergens op dit forum toch, gebruik je exact die code?

sjimmie schreef op dinsdag 24 januari 2017 @ 15:42:
[...]

Ja om die reden heb ik er bij mijzelf wat extra code in gezet.
Daarmee check ik of het ontvangen ID wel het ID is van mijn remote.

[ThinkPad]

Wat zijn op dit moment eigenlijk de verschillende sketches waar ik keuze uit heb als ik hiermee ga beginnen?
Ga binnenkort verhuizen en wil dan ook een nieuwe Itho Ecofan plaatsen om de huidige, onzuinige, ventilatiebox te vervangen.

Aansturing vanuit Home Assistant over MQTT ofzo zou top zijn omdat ik MQTT al gebruik om CO₂-waardes van huiskamer uit te lezen. Maar eerlijk gezegd ben ik het overzicht een beetje kwijt van welke code ik nou het beste kan pakken.

Er is niet toevallig een plugin voor ESPEasy?

[ Voor 11% gewijzigd door ThinkPad op 24-01-2017 16:17 ]

[sjimmie]

rorie schreef op dinsdag 24 januari 2017 @ 16:10:
Oke, die staat ook ergens op dit forum toch, gebruik je exact die code

Mijn code is die github.com/supersjmmie code.
Maar dat is de originele omdat die " gewoon werkt". Zelf werk ik offline met code met meerdere aanpassingen die dus niet online staan. Momenteel heb ik ff niet de resources om aan mijn code te werken.

[sjimmie]

@Thinkpad, je moet het eigenlijk niet bekijken als kant-en-klare sketches maar puur als libraries met een eenvoudige example sketch.
In die expample sketch staan een paar basale voorbeeldjes, maar de rest moet je zelf doen. Persoonlijk vind het ook niet goed om alles voor te kouwen, de bedoeling is dat de libraries worden gebruikt zoals ieder zelf wil. (het gebeurde al dat een uitgebreidere sketch niet bij iedereen werkte, en omdat die blind werd overgenomen ontstonden er problemen en discussies die helemaal niets met de libraries te maken hadden)

[Aniki]

Ik lees de verschillende topics over deze onderwerpen allemaal door, maar het is me nog niet duidelijk. Ik wil:

Co2 meten in verschillende ruimtes, waardes doorsturen naar een domotica-systeem die gebruikt kunnen worden door een controller op een WTW-unit met RF-ontvangmogelijkheden (maar heeft ook een perilex stekker)

Wat ik denk te weten:

Co2 meten met een MH-Z19 sensor geknoopt aan een ESP8266 wifi-module. Wat is het verschil met zoiets als een Wemos D1 mini? Dit is een wifi board aangedreven door een ESP8266 module.

Dan moet daar firmware op om gegevens door te sturen, Arduino of NodeMCU? Script kopieren en aanpassen van de echte slimme koppen in deze threads (klusjesman, sjimmie?)

Vervolgens moet je in Domotica software voorwaarden kunnen programmeren op basis van de CO2 (en hopelijk zometeen ook luchtvochtigheid) waarden die uiteindelijk de WTW aanstuurt.

Volgens mij kan dat op twee manieren: als het apparaat RFT ondersteunt, kan het met een CC1101 transceiver? Hoe krijgt dit signalen?

Als het geen RFT heeft, kun je een ACM-3-3500 aansluiten waarvoor je de perilex-stekker moet slopen. Daar heb ik wat schema's van gezien.

De volgende termen komen voorbij:
MQTT - connectivity protocol, maar verder geen idee…
InfluxDB - een database?
ESPEasy - zoiets als MQTT?
Wemos D1 Mini - een wifi board, waar gebruik je dit voor tov van een losse ESP8266 module?
CC1101 tranceiver - um
ACM-3-3500 - de klik-aan-uit schakelaar die je met afstandsbediening kunt bedienen. Kan ook andere signalen krijgen?

Mijn oprechte excuses voor de wartaal hierboven, ik heb alle relevante topics doorgespit, meerdere keren, maar deze technologie is mij zo nieuw dat het allemaal niet blijft plakken. Als ik het zo opsom, blijkt maar weet dat ik er echt nog niks van snap. Hopelijk helpt iemand me een beetje op weg..

[sjimmie]

Aniki schreef op woensdag 25 januari 2017 @ 16:48:
Ik lees de verschillende topics over deze onderwerpen allemaal door, maar het is me nog niet duidelijk. Ik wil:
...
Volgens mij kan dat op twee manieren: als het apparaat RFT ondersteunt, kan het met een CC1101 transceiver? Hoe krijgt dit signalen?

Als het geen RFT heeft, kun je een ACM-3-3500 aansluiten waarvoor je de perilex-stekker moet slopen. Daar heb ik wat schema's van gezien.

De enige overeenkomst met dit topic is het woordje RFT, maar ik vermoed dat je daarmee geen Itho RFT bedoelt. Aangezien je heel veel hele brede vragen stelt, zou ik voorstellen om naar het esp8266 topic of het Arduino topic te gaan. Daar is men (ik ook soms) met vanalles op dat vlak bezig.

[sjimmie]

Zojuist mijn code (lokale versie) bijgewerkt met de laatste bevindingen van hier.
Dus de standby Message2 van racquemis, de enum op de ooit bedachte 34, de counter-berekeningen van klusjesman.

Hij gaat niet naar de standby stand zoals bij klusjesman, maar doet wel meer dan bij racquemis.
Het is wederom wat ik al een poos geleden had: naar nul en telkens een paar sec naar low.

[Aniki]

sjimmie schreef op woensdag 25 januari 2017 @ 17:04:
[...]

De enige overeenkomst met dit topic is het woordje RFT, maar ik vermoed dat je daarmee geen Itho RFT bedoelt. Aangezien je heel veel hele brede vragen stelt, zou ik voorstellen om naar het esp8266 topic of het Arduino topic te gaan. Daar is men (ik ook soms) met vanalles op dat vlak bezig.

Sorry, maar dat bedoelde ik eigenlijk wel. Snap dat het nogal verwarrend overkwam. Gaat om een Itho wtw. Ik heb nu een oud model zonder rft en ga een nieuwe aanschaffen die dat wel ondersteunt. Als ik het goed begrijp is de klikaanklikuit methode ook te implementeren op units die geen rft ondersteunen. Aangezien de oude toch weggaat wilde ik al wat experimenteren. Maar als dat betekent dat ik later toch een ander systeem moet gebruiken, is het misschien niet slim.

Tussen het esp topic, co2 sensor topic, het vraagestuurde mechanische ventilatietopic en deze, leek deze me de meest toepasselijke... Zal die andere ook doorpluizen om meer te leren over esp8266 en arduino.

[racquemis]

sjimmie schreef op woensdag 25 januari 2017 @ 18:27:
Zojuist mijn code (lokale versie) bijgewerkt met de laatste bevindingen van hier.
Dus de standby Message2 van racquemis, de enum op de ooit bedachte 34, de counter-berekeningen van klusjesman.

Hij gaat niet naar de standby stand zoals bij klusjesman, maar doet wel meer dan bij racquemis.
Het is wederom wat ik al een poos geleden had: naar nul en telkens een paar sec naar low.

Vreemd ik gebruik de basis van je code met op dezelfde manier de niet thuis code toegevoegd en hier werkt het wel. Ik zal morgenochtend of vanavond wel effe mijn code posten.

[sjimmie]

racquemis schreef op woensdag 25 januari 2017 @ 19:08:
[...]


Vreemd ik gebruik de basis van je code met op dezelfde manier de niet thuis code toegevoegd en hier werkt het wel. Ik zal morgenochtend of vanavond wel effe mijn code posten.

Ik denk niet dat het een code-probleem is.
Mijn code, die van klusjesman en die van jou zijn in basis hwezelfde.
Het enige is de message2, de command nr 34 en de counters.
We gebruiken alledrie dezelfde message2 en command 34.
En wat betreft de opbouw van de counters heb jij hetgeen wat ik eerst al had getest en heb ik nu wat klusjesman heeft uitgedokterd.
Ik heb dus feitelijk hetzelfde als jij en hetzelfde als klusjesman gebruikt.

Wat bij klusjesman werkt, werkt niet bij jou.
en die van jou en van hem werken ook weer niet bij mij.
We missen dus ergens iets waardoor het nu nog telkens bij iedereen anders werkt...

[racquemis]

Er moet toch een verschil zijn. ik meld de CC1101 bij de Itho aan als dezelfde remote als jij gebruikt.
Dus dezelfde remote, dezelfde RF ontvanger print in de Itho (er is volgens mij maar 1 versie) dan zou het toch gewoon moeten werken?

Je kan altijd proberen de exact zelfde sketch als mij of klusjesman te draaien, als het dan niet werkt lijkt me dat het probleem zich in de RF ontvanger print in de Itho ligt. Misschien zijn er daar ook verschillende versies van?? Het is tenslotte een add-on.

EDIT:
Mijn gewijzigde versie van de library:
https://github.com/racquemis/IthoEcoFanRFT

[ Voor 8% gewijzigd door racquemis op 26-01-2017 09:58 ]

[edjeed]

racquemis schreef op woensdag 25 januari 2017 @ 21:45:
Er moet toch een verschil zijn. ik meld de CC1101 bij de Itho aan als dezelfde remote als jij gebruikt.
Dus dezelfde remote, dezelfde RF ontvanger print in de Itho (er is volgens mij maar 1 versie) dan zou het toch gewoon moeten werken?

Je kan altijd proberen de exact zelfde sketch als mij of klusjesman te draaien, als het dan niet werkt lijkt me dat het probleem zich in de RF ontvanger print in de Itho ligt. Misschien zijn er daar ook verschillende versies van?? Het is tenslotte een add-on.

EDIT:
Mijn gewijzigde versie van de library:
https://github.com/racquemis/IthoEcoFanRFT

Volgens deze code sync je op 172 bij messagereceive1

writeRegister(CC1101_SYNC1 ,172);

Klopt dit wel? ik sync daar op 170 (net zoals jvdmast en klusjesman)

[racquemis]

Ja dit klopt, dit is een specifieke wijziging voor mijn remote. Zal ik even moeten veranderen in de code om het compatible te maken met de rft remote.

Wanneer ik sync op 170 ontvang ik allen maar onzin van de remote. Via de logic analyzer gekeken wat er daadwerkelijk verstuurd werd toen ik erachter kwam dat de sync byte bij mijn remote anders is
Na wijziging werden de commando's ineens netjes herkend.

Dit is bijvoorbeeld wat er verstuurd van de niet thuis code. maar de eerste vijf bytes van messag1 zijn bij mij bij elk commando hetzelfde

code:

Message1
170 170 170 172 173 45 44 203 84 171 85 53 84 204 205 84 170 171 85 75 
Message2
170 170 170 170 170 170 170 171 254 0 179 42 171 42 149 154 101 90 170 105 169 166 169 166 85 153 102 89 150 170 165 101 90 150 85 149 101 90 86 85 150 102 154 106 172 170 170 170 170 170

Misschien dat de bytes die wel als sync gebruiken wellicht toch onderdeel zijn van het commando?

[ Voor 11% gewijzigd door racquemis op 26-01-2017 13:05 ]

[sjimmie]

Sowieso is mijn bevinding dat heel message1 hier niet nodig is, mijn itho reageert ook als ik alleen message2 stuur. Dus ik heb zowel het zenden als het ontvangen van message1 helemaal uit mijn code gesloopt, dat scheelt weer performance (vooral omdat ik een met interrupt ben gaan werken is dat belangrijk).
Ik denk dat message1 een soort backwards compatibility is voor oudere modellen (geen idee dus of dat voor jullie wel van toepassing is!).

Dat is voor mij de reden dat ik alleen nog maar naar een werkende message2 met standby hoef te zoeken.

EDIT:

racquemis schreef op woensdag 25 januari 2017 @ 21:45:
Mijn gewijzigde versie van de library:
https://github.com/racquemis/IthoEcoFanRFT

Ik heb jouw code vergeleken met de mijne en er zit slechts 1 verschilletje in.
In calculateMessage2Byte43 stel jij de Away hetzelfde in als Low enzo, en ik neem daar de code van klusjesman die byte43 anders berekent voor Away.
Echter, in mijn eerdere pogingen had ik daar wel precies wat jij nu hebt, dus dat is het niet.

[ Voor 32% gewijzigd door sjimmie op 26-01-2017 18:47 ]

[deklusjesman]

Waarom gebruiken jullie ook niet hetzelfde deviceId als mijn code? Dan kan het niet anders dan dat het werkt. Misschien dat er voor message2 toch nog iets uit dat deviceId gebruikt wordt in de berekening van byte43. Bij de Duco remote is dat volgens mij het geval. De counter bytes voor leave en join bevatten ook een andere berekening voor de Duco, maar die heb ik weer uit mijn code gehaald. De verschillen van berekenen voor byte43 heb ik wel in de code laten staan (command duco_xxx).

De message2 bytes zijn bij iedereen hetzelfde. Ik heb nog geen verschillen aangetroffen. Bij message1 is dit een ander verhaal.

Message1 zou ook kunnen bestaan om de bereikbaarheid te vergroten als de ontvangst slecht is. Message1 wordt op een iets andere frequentie gestuurd toch? Weet t anders ook niet. Die fan trekt message1 in elk geval wel uit de lucht.

Als je de standby berekent zoals de low dan is de berekening in 50% van de gevallen goed, dus dan krijg je wat racquemis al eerder beschreef, de ene keer doet ie het wel, de andere keer niet.

Op mijn Duco c system remote heb ik 170 in de sync byte staan. Wat ik wel ondervonden heb is dat een byte in het bericht die ik ter controle gebruikte bij de Duco altijd op 169 staat ipv 170.

Message1 verzend ik niet meer en alles werkt correct. Voor het ontvangen gebruik ik message1 nog wel. Maar alleen om te bepalen welk bericht type 2 ik ga ontvangen (join, leave, control). Dit vanwege de lengte van de berichten.

Ik heb command 33 kort uitgetest eerder deze week en dat is in elk geval geen command om de fan uit te zetten. Misschien dat die ergens rond de join\leave te vinden is. Dit lijkt me nog het enige zinvolle command als die bestaat.