DIY: Itho ventilatie aansturen via 868Mhz transmitter

[Speedy-Andre]

Het was niet mijn vraag, bij mij zit in Domoticz alleen een 5-voudige switch die http commando's stuurt.
Als ik die switch niet gebruik zal Domoticz idd geen dataverkeer genereren.
Dan kan het alleen nog tussen de Esp en de router zijn, bij mij geeft de router de snelheid van wifi naar elke client aan en misschien veroorzaakt dat enig verkeer

[grote_oever]

sjimmie schreef op maandag 9 oktober 2017 @ 14:45:
[...]

Ik snap niet zo goed wat je bedoelt.
De itho controller (waar we het hier over hebben) is een 868MHz device, hoe zie jij dan dat die met jouw netwerk verbonden is en verkeer genereert?

Ik bedoel met de Itho controller inderdaad de ESP controller. Haal termen beetje door elkaar. Enige wat de ESP doet is twee keer per dag fan aanzetten en daarna weer uit. Weet niet of er tussentijds gepolled wordt. Vond alle de dataverkeer best wel veel. Vandaar de vraag.

[Ierlandfan]

@sjimmie Kun je toevallig het relevante stukje code delen? Dan kunnen we wellicht zelf iets in elkaar zetten.

[sjimmie]

grote_oever schreef op maandag 9 oktober 2017 @ 17:27:
[...]


Ik bedoel met de Itho controller inderdaad de ESP controller. Haal termen beetje door elkaar. Enige wat de ESP doet is twee keer per dag fan aanzetten en daarna weer uit. Weet niet of er tussentijds gepolled wordt. Vond alle de dataverkeer best wel veel. Vandaar de vraag.

Als je domoticz gebruikt dan zal het meeste verkeer daardoor komen. Geen idee wat domoticz allemaal nog meer doet. Qua itho doet de esp, als het goed is, niets anders dan luisteren. En alleen als je op een knop van de controller drukt zal de esp dat ontvangen en dan iets over het netwerk doen.
Nogmaals, er is niet zoiets als pollen want het is 1-richtingsverkeer: de controller stuurt iets en anders gebeurt er niets. (of je esp verstuurt iets, maar dat ook alleen als jij/domoticz dat aanstuurt)

Ierlandfan schreef op dinsdag 10 oktober 2017 @ 07:53:
@sjimmie Kun je toevallig het relevante stukje code delen? Dan kunnen we wellicht zelf iets in elkaar zetten.

Sorry, ik ben er even een beetje uit, welk relevante stukje zoek je?

[Ierlandfan]

@sjimmie

Ik heb in mijn code, die een groot web van allerlei eigen home-dingetjes is, zowel de mogelijkheid om een snelheid te verzenden als om constant te luisteren naar de andere "fysieke zender".
Dat is echter dusdanig door mijn grote project verweven dat ik die code niet zo even pasklaar kan posten.

[sjimmie]

Ierlandfan schreef op dinsdag 10 oktober 2017 @ 10:51:
@sjimmie

[...]

Oef, in grove stappen...
Een boolean dit bijhoudt of er een packet is ontvangen:

C++:

bool ITHOhasPacket = false;

Dan een interrupt aan de cc1101 interrupt pin:

C++:

void setup() {
//...
  attachInterrupt(ITHO_IRQ_PIN, ITHOinterrupt, RISING);
}

In de loop kijk ik dan regelmatig of de boolean true is geworden:

C++:

void loop() {
// do whatever you want
  if (ITHOhasPacket) {
    ITHOshowPacket();
}

Omdat de cc1101 interrupt pin al hoog wordt zodra er een bitje binnenkomt heb ik een korte vertraging voordat het uitlezen wordt gestart:

C++:

inline static void ICACHE_RAM_ATTR  __attribute__((always_inline)) ITHOinterrupt() {
  ITHOticker.once_ms(10, ITHOcheck);
}

Dan wordt de data uitgelezen en in wat variabelen gezet(die zal je zelf even bij elkaar moeten schrapen):

C++:

void ITHOcheck() {
  if (rf.checkForNewPacket()) {
    IthoCommand cmd = rf.getLastCommand();
    if (++RFTcommandpos > 2) RFTcommandpos = 0;  // store information in next entry of ringbuffers
    RFTcommand[RFTcommandpos] = cmd;
    RFTRSSI[RFTcommandpos]    = rf.ReadRSSI();
    bool chk = rf.checkID(RFTid);
    RFTidChk[RFTcommandpos]   = chk;
    if ((cmd != IthoUnknown) && chk) {  // only act on good cmd and correct id.
      ITHOhasPacket = true;
    }
  }
}

Omdat de itho zender 3 keer hetzelfde verstuurt en die 3 niet altijd goed worden ontvangen, heb ik een controle-functie:

C++:

uint8_t findRFTlastCommand() {
  if (RFTcommand[RFTcommandpos] != IthoUnknown)               return RFTcommandpos;//RFTcommand[RFTcommandpos];
  if ((RFTcommandpos == 0) && (RFTcommand[2] != IthoUnknown)) return 2;//RFTcommand[2];
  if ((RFTcommandpos == 0) && (RFTcommand[1] != IthoUnknown)) return 1;//RFTcommand[1];
  if ((RFTcommandpos == 1) && (RFTcommand[0] != IthoUnknown)) return 0;//RFTcommand[0];
  if ((RFTcommandpos == 1) && (RFTcommand[2] != IthoUnknown)) return 2;//RFTcommand[2];
  if ((RFTcommandpos == 2) && (RFTcommand[1] != IthoUnknown)) return 1;//RFTcommand[1];
  if ((RFTcommandpos == 2) && (RFTcommand[0] != IthoUnknown)) return 0;//RFTcommand[0];
  return -1;
}

En een functie om de ontvangen code weer te geven:

C++:

void ITHOshowPacket()    {
  ITHOhasPacket = false;
  uint8_t goodpos = findRFTlastCommand();
  if (goodpos != -1)  RFTlastCommand = RFTcommand[goodpos];
  else                RFTlastCommand = IthoUnknown;
  //show command
  Serial.print(F("RFT Current Pos: "));
  Serial.print(RFTcommandpos);
  Serial.print(F(", Good Pos: "));
  Serial.println(goodpos);
  Serial.print(F("Stored 3 commands: "));
  Serial.print(RFTcommand[0]);
  Serial.print(F(" "));
  Serial.print(RFTcommand[1]);
  Serial.print(F(" "));
  Serial.print(RFTcommand[2]);
  Serial.print(F(" / Stored 3 RSSI's:     "));
  Serial.print(RFTRSSI[0]);
  Serial.print(F(" "));
  Serial.print(RFTRSSI[1]);
  Serial.print(F(" "));
  Serial.print(RFTRSSI[2]);
  Serial.print(F(" / Stored 3 ID checks: "));
  Serial.print(RFTidChk[0]);
  Serial.print(F(" "));
  Serial.print(RFTidChk[1]);
  Serial.print(F(" "));
  Serial.print(RFTidChk[2]);
  Serial.print(F(" / Last ID: "));
  Serial.print(rf.getLastIDstr());

  Serial.print(F(" / Command = "));
  switch (RFTlastCommand) {
    case IthoUnknown:
      Serial.print(F("unknown\n"));
      break;
    case IthoLow:
      Serial.print(F("low\n"));
      RFTstate = RFTlastCommand;
      break;
    case IthoMedium:
      Serial.print(F("medium\n"));
      RFTstate = RFTlastCommand;
      break;
    case IthoFull:
      Serial.print(F("full\n"));
      RFTstate = RFTlastCommand;
      break;
    case IthoTimer1:
      Serial.print(F("timer1\n"));
      RFTstate = RFTlastCommand;
      break;
    case IthoTimer2:
      Serial.print(F("timer2\n"));
      RFTstate = RFTlastCommand;
      break;
    case IthoTimer3:
      Serial.print(F("timer3\n"));
      RFTstate = RFTlastCommand;
      break;
    case IthoJoin:
      Serial.print(F("join\n"));
      break;
    case IthoLeave:
      Serial.print(F("leave\n"));
      break;
  }
}

Dat zal het ongeveer wel zijn.
Er wordt gebruikgemaakt van 3 functies die ik in de library heb zitten:
rf.checkForNewPacket()
rf.getLastCommand()
rf.checkID(RFTid)
rf.ReadRSSI()
Die staan in de volgende post.

[sjimmie]

De functies in de library:

In de IthoCC1101.cpp:

C++:

bool IthoCC1101::checkForNewPacket()
{
    if (receiveData(&inMessage2, 42))
    {
        parseMessageCommand();
        initReceiveMessage2(IthoUnknown);
        return true;
    }   
    
    return false;
}

uint8_t IthoCC1101::ReadRSSI()
{
  uint8_t rssi = 0;
  uint8_t value = 0;

  rssi = (readRegister(CC1101_RSSI, CC1101_STATUS_REGISTER));

  if (rssi >= 128)
  {
    value = 255 - rssi;
    value /= 2;
    value += 74;
  }
  else
  {
    value = rssi / 2;
    value += 74;
  }
  return(value);
}

bool IthoCC1101::checkID(const uint8_t *id)
{
    for (uint8_t i=0; i<8;i++)
        if (id[i] != inIthoPacket.deviceId[i])
            return false;
    return true;
}

String IthoCC1101::getLastIDstr() {
    String str;
    for (uint8_t i=0; i<8;i++) {
        str += String(inIthoPacket.deviceId[i], HEX);
        if (i<7) str += "-";
    }
    return str;
}

En in de .h file in het public deel van de IthoCC1101 class:

C++:

class IthoCC1101 : protected CC1101
public:
        bool checkForNewPacket();                                               //check RX fifo for new data
        IthoPacket getLastPacket() { return inIthoPacket; }                     //retrieve last received/parsed packet from remote
        IthoCommand getLastCommand() { return inIthoPacket.command; }                       //retrieve last received/parsed command from remote
        uint8_t getLastInCounter() { return inIthoPacket.counter; }                     //retrieve last received/parsed command from remote
        uint8_t ReadRSSI();
        bool checkID(const uint8_t *id);
        String getLastIDstr();

[remcoXP]

ik hoop nog steeds dat iemand dit als plugin voor easpeasy kan fixxen. ik heb twee esp easy's in gebruik en werken echt goed.

[ThinkPad]

remcoXP schreef op woensdag 11 oktober 2017 @ 21:39:
ik hoop nog steeds dat iemand dit als plugin voor easpeasy kan fixxen. ik heb twee esp easy's in gebruik en werken echt goed.

Beter zoeken dan, dat heb ik in juli dit jaar namelijk al voor elkaar kunnen krijgen
ThinkPadd in "DIY: Itho ventilatie aansturen via 868Mhz transmitter"

Draait nog steeds prima hier.

[Whizzer]

Maar niet bij iedereen helaas..

[Ierlandfan]

@ThinkPad Zit daar dan ook zenden EN ontvangen in?

[ThinkPad]

@Ierlandfan Alleen zenden.

[sjimmie]

Maar wacht, er is meer...

Ten eerste in de IthoCC1101.cpp:

C++:

void IthoCC1101::initReceive()
...
    writeRegister(CC1101_IOCFG2 ,0x00);         //Assert when RX FIFO is filled or above the RX FIFO threshold. Deassert when (0x00): RX FIFO is drained below threshold, or (0x01): deassert when RX FIFO is empty.
...

Dit regelt de IO2 pin en stelt die in om een interrupt te geven als er data ontvangen wordt.
Die pin gaat dus extra als interrupt naar de esp zoals in de eerdere posts stond.

En dan, ingrijpender, heb ik gezorgd dat ik alleen nog luister naar de Message2 berichten.
Dat voorkomt dat er telkens geschakeld moet worden van de ene naar de andere ontvangstmodus.

Ik weet even niet hoe ik dat qua code kort ga samenvatten.
In ieder geval wederom in de IthoCC1101.cpp, op de laatste regel van de functie IthoCC1101::initReceive():

C++:

    initReceiveMessage2(IthoUnknown);

In plaats van een initReceiveMessage1().

[rorie]

Vraagje, ik gebruik de code van "Klusjesman" voor nu ongeveer een jaar. Draait op een NodeMcu ESP8266 i.c.m. een luchtvochtigheidssensor in de badkamer welke zelfstandig mijn ITHO ventilatie automatisch in en uit schakelt. Dit werkt allemaal perfect alleen de laatste maand schakelt hij heel af en toe mijn ITHO niet meer uit. Het lijkt er op dat het sendLow command niet goed verstuurd / ontvangen word.

Loop jij ook wel eens tegen dit probleem aan? Of zijn er code wijzigingen geweest in de code van klusjesmand of door jou die deze kunnen verhelpen?

sjimmie schreef op zondag 15 oktober 2017 @ 19:04:
Maar wacht, er is meer...

Ten eerste in de IthoCC1101.cpp:

C++:

void IthoCC1101::initReceive()
...
    writeRegister(CC1101_IOCFG2 ,0x00);         //Assert when RX FIFO is filled or above the RX FIFO threshold. Deassert when (0x00): RX FIFO is drained below threshold, or (0x01): deassert when RX FIFO is empty.
...

Dit regelt de IO2 pin en stelt die in om een interrupt te geven als er data ontvangen wordt.
Die pin gaat dus extra als interrupt naar de esp zoals in de eerdere posts stond.

En dan, ingrijpender, heb ik gezorgd dat ik alleen nog luister naar de Message2 berichten.
Dat voorkomt dat er telkens geschakeld moet worden van de ene naar de andere ontvangstmodus.

Ik weet even niet hoe ik dat qua code kort ga samenvatten.
In ieder geval wederom in de IthoCC1101.cpp, op de laatste regel van de functie IthoCC1101::initReceive():

C++:

    initReceiveMessage2(IthoUnknown);

In plaats van een initReceiveMessage1().

[sjimmie]

rorie schreef op woensdag 8 november 2017 @ 08:47:
Vraagje, ik gebruik de code van "Klusjesman" voor nu ongeveer een jaar. Draait op een NodeMcu ESP8266 i.c.m. een luchtvochtigheidssensor in de badkamer welke zelfstandig mijn ITHO ventilatie automatisch in en uit schakelt. Dit werkt allemaal perfect alleen de laatste maand schakelt hij heel af en toe mijn ITHO niet meer uit. Het lijkt er op dat het sendLow command niet goed verstuurd / ontvangen word.

Loop jij ook wel eens tegen dit probleem aan? Of zijn er code wijzigingen geweest in de code van klusjesmand of door jou die deze kunnen verhelpen?


[...]

Dat komt me niet bekend voor.
Wellicht is je antenne wat aan de zwakke kant (verplaatst, verschoven, losgeraakt) en zit je op het randje qua bereik? Nou gebruik ik maar zelden het verzenden dus een misser zou hier nieteens echt opvallen, dus wellicht is het wel een probleem wat ik niet zie... Het kan een bitje zijn wat in de berekening soms niet klopt, maar dat is best complex en moeilijk te debuggen. Want ieder volgend bericht is weer een beetje afhankelijk van de vorige, dus een low na een high is weer anders dan na een medium,en de volgende keer istie ook na een high weer anders omdat de teller weer verder is.

Er zijn 2 snelle fixes die je kan proberen,
1 is dezelfde low code wat vaker laten verzenden zodat de kans groter is dat het na een aantal keren wel ontvangen wordt,
2 is meerdere keren een opvolgende low code er achteraan sturen zodat een eventuele eenmalige rekenfout wordt hersteld.

Ik kijk later ff in de code hoe je 1 en 2 regelt.

[M.v.Veelen]

Ik heb al enige tijd de Wemos D1 Mini draaien met de ESPeasy die Thinkpad heeft gecompiled. Nu heb ik echter al mijn andere Wemos en Sonoffs met Tasmota draaien en vroeg ik me af of iemand weet of ik m'n Wemos met Tasmota de ITHO ook kan laten aansturen.

[rorie]

@sjimmie Volgens mij heb ik wel eens gelezen hier dat de C++ code al standaard 3 x een pakketje verstuurd, bijvoorbeeld bij een low of high, klopt dit?

[ Voor 8% gewijzigd door rorie op 21-11-2017 20:39 ]

[sjimmie]

rorie schreef op dinsdag 21 november 2017 @ 20:38:
@sjimmie Volgens mij heb ik wel eens gelezen hier dat de C++ code al standaard 3 x een pakketje verstuurd, bijvoorbeeld bij een low of high, klopt dit?

Klopt, net als de originele remote verzendt de code ook 3x hetzelfde packet.
https://github.com/supers...ter/Itho/IthoCC1101.h#L84

C++:

        IthoCC1101(uint8_t counter = 0, uint8_t sendTries = 3);     //set initial counter value

https://github.com/supers.../Itho/IthoCC1101.cpp#L766

C++:

    uint8_t maxTries = sendTries;

https://github.com/supers.../Itho/IthoCC1101.cpp#L799

C++:

    for (int i=0;i<maxTries;i++)

Ik weet uit de praktijk dat 1x vaak misgaat en dat zelfs 2x niet ideaal is.
Mijn recieve-code ontvangt er doorgaans ook maar 1 of 2 vanaf de originele remote.

[Ierlandfan]

Voordat ik een Chinese vriend (Ali Express) ga helpen (*spekken*) met een bestelling:
NodeMCU (Lolin) of Wemos werkt? Laat ik het zo zeggen in mijn geval, zenden werk, ontvangen niet.
Pinout: 6 en 7 zijn niet aangesloten. Ik zie wat conflicterende pinouts hier op het forum (7 en 8 zijn soms omgedraaid)
Ik las wat over parallel en SPI. Is dat een andere Pinout?

Het is meer dat ik probeer te begrijpen waarom het ontvangen niet zou kunnen werken.

[rorie]

Er zijn meerdere mensen geweest hier die problemen hadden met de Wemos, zou gewoon een NodeMCU bordje bestellen. Mocht je dit te lang vinden duren en in de buurt van Rotterdam wonen dan heb ik er nog wel een voor je.

[Ierlandfan]

Er hangt nu een NodemCU aan (Was Wemos) en die doet precies hetzelfde. Heb ook nog een Lolin ESP32 Lora (443mhz) en een NodeMCU ESP32 maar om dat allemaal te proberen...
Ik dacht daarom om alleen even het receive gedeelte te flashen, kijken of dat werkte...het geeft "join command sent" , "start "(Dat hoort) en daarna kan ik op allerlei knoppen drukken op de remote maar er verschijnt niets op de console. Zenden werkt echter prima...

[M.v.Veelen]

Ierlandfan schreef op vrijdag 24 november 2017 @ 22:35:
Er hangt nu een NodemCU aan (Was Wemos) en die doet precies hetzelfde. Heb ook nog een Lolin ESP32 Lora (443mhz) en een NodeMCU ESP32 maar om dat allemaal te proberen...
Ik dacht daarom om alleen even het receive gedeelte te flashen, kijken of dat werkte...het geeft "join command sent" , "start "(Dat hoort) en daarna kan ik op allerlei knoppen drukken op de remote maar er verschijnt niets op de console. Zenden werkt echter prima...

Moet je niet ipv op de knoppen te drukken, de ITHO even stroomloos maken en bijtijds weer de stroom er op zetten ?

Overigens heb ik 0 (nul) problemen met de Wemos

[jvdzande]

M.v.Veelen schreef op vrijdag 24 november 2017 @ 22:42:
[...]
Overigens heb ik 0 (nul) problemen met de Wemos

.. en je ontvangt ook de commando's van de standaard remote op je ESPEASY op de Wemos?
Ik gebruik ook de Wemos voor zenden en dat werkt inderdaad perfect, maar zou het best wel leuk vinden als ik ook de commando's van de standaard itho remote zou ontvangen om dat in Domoticz te kunnen weergeven.
Ik heb geprobeerd de gevonden stukken code aan de ESPEASY code toe te voegen, maar het is me niet gelukt om commando's te ontvangen.

Jos

[ Voor 12% gewijzigd door jvdzande op 25-11-2017 11:25 ]

[M.v.Veelen]

Nee, niet dat ik weet. Ik heb ook al zolang de standaard remotes niet meer gebruikt......? Ik weet niet eens waar ze liggen zelfs.

[Ierlandfan]

Ik denk dat de CC1101 gewoon (half) DOA is. Aangezien het bijna SInterklaas is heb ik 3 nieuwe CC1101's gekocht voor het wereldbedrag van 6, 50 (inc shipping)

[rorie]

Zelf stuur ik ook mijn Itho eco fan aan met een NodeMCU ESP8266 met daarop aangesloten een CC1101 module. Ook lees ik de stand van mijn twee losse handzenders uit en toon ik die in mijn zelfgemaakte web intetrface. Zo kan ik bijvoorbeeld zien dan mijn Itho eco fan vanuit de wc op stand 3 is gezet en zet mijn ESP8266 deze na 10 minuten automatisch weer uit.

Hiervoor heb ik de volgende aanpassingen gedaan aan de C++ code:

Toevoeging onderaan IthoCC1101.cpp:

code:

bool IthoCC1101::checkID(const uint8_t *id)
{
    for (uint8_t i=0; i<8;i++)
        if (id[i] != inIthoPacket.deviceId[i])
            return false;
    return true;
}

String IthoCC1101::getLastIDstr() {
    String str;
    for (uint8_t i=0; i<8;i++) {
        str += String(inIthoPacket.deviceId[i], HEX);
        if (i<7) str += "-";
    }
    return str;
}

Toevoeging aan IthoCC1101.h in de sectie 'public:':

code:

bool checkID(const uint8_t *id);
String getLastIDstr();

Met bijv String myID = rf.getLastIDstr() krijg je het ID van de laatst ingedrukte knop terug.

[jvdzande]

@rorie, Dank je voor het delen van je aanpassingen.
Even een paar vragen:
Welke versie gebruik je als de basis lib, want er zijn wat verschillende versies?
Misschien kan je jouw versie ergens delen zodat ik de juiste combinatie heb en even met die versie kan spelen of dat ook met de Wemos werkt?
Moeten er ook nog extra draadjes tussen de ESP en C1101 aangesloten worden om te kunnen ontvangen?

Dank je,
Jos

[ Voor 13% gewijzigd door jvdzande op 27-11-2017 19:53 ]

[iMars]

ThinkPadd schreef op zaterdag 1 juli 2017 @ 14:40:
[...]


[...]

Vandaag is jullie geluksdag

Het is mij gelukt om de HTTP variant die ik hier al eens had gemaakt om te vormen tot een plugin voor ESPEasy

Zie mijn Bitbucket: _P054_Itho.ino en hieronder geplakt als backup.

C++:

//#######################################################################################################
//############################## Plugin 054: Itho ventilation unit 868Mhz remote ########################
//#######################################################################################################

// List of commands:
// JOIN to join ESP8266 with Itho ventilation unit
// LOW - set Itho ventilation unit to lowest speed
// MEDIUM - set Itho ventilation unit to medium speed
// HIGH - set Itho ventilation unit to max speed

// Usage (not case sensitive):
// http://ip/control?cmd=ITHOSEND,join
// http://ip/control?cmd=ITHOSEND,low
// http://ip/control?cmd=ITHOSEND,medium
// http://ip/control?cmd=ITHOSEND,high


//This code needs the library made by 'supersjimmie': https://github.com/supersjimmie/IthoEcoFanRFT/tree/master/Master/Itho
// A CC1101 868Mhz transmitter is needed
// See https://gathering.tweakers.net/forum/list_messages/1690945 for more information

#include <SPI.h>
#include "IthoCC1101.h"
#include "IthoPacket.h"
IthoCC1101 rf;
IthoPacket packet;

#define PLUGIN_054
#define PLUGIN_ID_054         54
#define PLUGIN_NAME_054       "Itho ventilation remote"
#define PLUGIN_VALUENAME1_054 ""
boolean Plugin_054(byte function, struct EventStruct *event, String& string)
{
    boolean success = false;

    switch (function)
    {

        case PLUGIN_DEVICE_ADD:
        {
            Device[++deviceCount].Number = PLUGIN_ID_054;
            break;
        }

        case PLUGIN_GET_DEVICENAME:
        {
            string = F(PLUGIN_NAME_054);
            break;
        }

        case PLUGIN_GET_DEVICEVALUENAMES:
        {
            break;
        }

        case PLUGIN_INIT:
        {
            rf.init();
            //rf.sendCommand(IthoJoin);
            addLog(LOG_LEVEL_INFO, F("CC1101 868Mhz transmitter initialized"));
            success = true;
            break;
        }

        case PLUGIN_WRITE: {

            String tmpString = string;

            String cmd = parseString(tmpString, 1);
            String param1 = parseString(tmpString, 2);


            if (cmd.equalsIgnoreCase(F("ITHOSEND")))
            {

                if (param1.equalsIgnoreCase(F("join")))
                {
                    rf.sendCommand(IthoJoin);
                    addLog(LOG_LEVEL_INFO, F("Sent command for 'join' to Itho unit"));
                    printWebString += F("Sent command for 'join' to Itho unit");
                    success = true;
                }

                if (param1.equalsIgnoreCase(F("leave")))
                {
                    rf.sendCommand(IthoLeave);
                    addLog(LOG_LEVEL_INFO, F("Sent command for 'leave' to Itho unit"));
                    printWebString += F("Sent command for 'leave' to Itho unit");
                    success = true;
                }

                if (param1.equalsIgnoreCase(F("low")))
                {
                    rf.sendCommand(IthoLow);
                    addLog(LOG_LEVEL_INFO, F("Sent command for 'low speed' to Itho unit"));
                    printWebString += F("Sent command for 'low speed' to Itho unit");
                    success = true;
                }

                if (param1.equalsIgnoreCase(F("medium")))
                {
                    rf.sendCommand(IthoMedium);
                    addLog(LOG_LEVEL_INFO, F("Sent command for 'medium speed' to Itho unit"));
                    printWebString += F("Sent command for 'medium speed' to Itho unit");
                    success = true;
                }

                if (param1.equalsIgnoreCase(F("high")))
                {
                    rf.sendCommand(IthoFull);
                    addLog(LOG_LEVEL_INFO, F("Sent command for 'full speed' to Itho unit"));
                    printWebString += F("Sent command for 'full speed' to Itho unit");
                    success = true;
                }

                if (param1.equalsIgnoreCase(F("timer1")))
                {
                    rf.sendCommand(IthoTimer1);
                    addLog(LOG_LEVEL_INFO, F("Sent command for 'timer 1' to Itho unit"));
                    printWebString += F("Sent command for 'timer 1' to Itho unit");
                    success = true;
                }               

                if (param1.equalsIgnoreCase(F("timer2")))
                {
                    rf.sendCommand(IthoTimer2);
                    addLog(LOG_LEVEL_INFO, F("Sent command for 'timer 2' to Itho unit"));
                    printWebString += F("Sent command for 'timer 2' to Itho unit");
                    success = true;
                }       

                if (param1.equalsIgnoreCase(F("timer3")))
                {
                    rf.sendCommand(IthoTimer3);
                    addLog(LOG_LEVEL_INFO, F("Sent command for 'timer 3' to Itho unit"));
                    printWebString += F("Sent command for 'timer 3' to Itho unit");
                    success = true;
                }   

            }
        }

    break;
    }
    return success;
}

HTTP:
http://192.168.6.25/control?cmd=ITHOSEND,join
http://192.168.6.25/control?cmd=ITHOSEND,low
http://192.168.6.25/control?cmd=ITHOSEND,medium
http://192.168.6.25/control?cmd=ITHOSEND,high

MQTT:

mosquitto_pub -t /IthoRemote/cmd -m ithosend,join
mosquitto_pub -t /IthoRemote/cmd -m ithosend,low
mosquitto_pub -t /IthoRemote/cmd -m ithosend,medium
mosquitto_pub -t /IthoRemote/cmd -m ithosend,high

(mijn devicename is 'IthoRemote', kun je instellen via tabje 'Config' in de WebGUI).
Helaas nog niet kunnen ontdekken hoe ik kan zorgen voor terugkoppeling via MQTT.

Ik ben geen C/C++ programmeur, dus het zou kunnen dat er wat bugs in zitten. Uiteraard heb je wel de library van supersjimmie nodig.

Voor de luie mensen, hier een kant-en-klare binary: IthoRemote_ESPEasy2.0.bin (gebaseerd op ESPEasy 'Release v2.0.0-dev10') zodat je de Arduino IDE en libraries e.d. niet nodig hebt. Flashen kan met deze tools (uitpakken, .bin in dezelfde folder zetten en dan FlashESP8266.exe uitvoeren)

Enjoy!

Vraagje, ik heb jouw code gebruikt om in Esp Easy MEGA te compilen met Arduino. Dit gaat allemaal goed, geen foutmeldingen. Uploaden en verder configureren.

Als ik op de serialport kijk, zie ik het volgende:

INIT : Booting version: (custom)
INIT : Warm boot #17
FS   : Mounting...
FS   : Mount successful, used 72288 bytes of 2949250
INIT : Free RAM:24856
INIT : I2C
INIT : SPI Init (without CS)
WIFI : AP Mode disabled
WIFI : AP Mode ssid will be IthoEspEasy_0 with address 192.168.4.1
WIFI : Connecting iRouter attempt #1
WIFI : Connected! IP: 10.0.0.101 (IthoEspEasy_0)
CC1101 868Mhz transmitter initialized
MQTT : Connected to broker
Subscribed to: itho/out
WD   : Uptime 0 ConnectFailures 0 FreeMem 22424

So far so good... maar zodra ik een commando geef:

code:

http://10.0.0.101/control?cmd=ITHOSEND,join
http://10.0.0.101/control?cmd=ITHOSEND,low
http://10.0.0.101/control?cmd=ITHOSEND,medium
http://10.0.0.101/control?cmd=ITHOSEND,high

Dan komt er Send op de serialport, en crasht de ESP (Wemos Mini D1).

Het enige wat ik in ESPEasy aangepast heb, is m'n WiFi, MQTT en de ITHO enabled. Daarnaast heb ik het met SPI aan en uit geprobeerd, maar alles crasht

[ThinkPad]

@iMars Probeer het eens met de kant-en-klare binary die ik destijds had gepost.
Wellicht doet die het beter, volgens mij heb ik daar alle overbodige plugins uit gestript.

Verder helaas niet echt een idee, ben niet iemand die dagelijks aan het programmeren is, was meer op goed geluk en met logisch verstand wat dingen proberen

[iMars]

ThinkPadd schreef op woensdag 6 december 2017 @ 19:49:
@iMars Probeer het eens met de kant-en-klare binary die ik destijds had gepost.
Wellicht doet die het beter, volgens mij heb ik daar alle overbodige plugins uit gestript.

Verder helaas niet echt een idee, ben niet iemand die dagelijks aan het programmeren is, was meer op goed geluk en met logisch verstand wat dingen proberen

Dat was de "matig trick"

INIT : Booting version: (custom)
INIT : Warm boot #3
FS   : Mounting...
FS   : Mount successful, used 72288 bytes of 2949250
INIT : Free RAM:28168
INIT : I2C
INIT : SPI not enabled
WIFI : AP Mode disabled
WIFI : AP Mode ssid will be ithoremote_0 with address 192.168.4.1
WIFI : Connecting iRouter attempt #1
WIFI : Connected! IP: 10.0.0.101 (ithoremote_0)
CC1101 868Mhz transmitter initialized
MQTT : Connected to broker
Subscribed to: ithoremote/out
EVENT: System#Boot
WD   : Uptime 0 ConnectFailures 0 FreeMem 26056
send
    Sent command for 'join' to Itho unit
send
    Sent command for 'join' to Itho unit
send
    Sent command for 'full speed' to Itho unit
send
    Sent command for 'full speed' to Itho unit

[ThinkPad]

Goedzo 👍🏻

[iMars]

@ThinkPad Hoe heb jij je mqtt ingesteld? Want wat ik ook publish, alleen via de url reageert ie.

Edit: veranderd naar OpenHAB MQTT:

mosquitto_pub -u *** -P *** -t '/ithoremote/cmd' -m 'ITHOSEND,high' 

Nu werkt het wel

Edit 2:

[ Voor 58% gewijzigd door iMars op 06-12-2017 22:35 ]

[arnord]

@ThinkPad bedankt voor je handige sketches; heb het na een avondje "knutselen" werkend gekregen in mijn openhab2 domotica.

[vso]

Misschien heb ik er overheen gelezen, maar wat heb ik nu nodig om dit werkend te krijgen (hw)
en moet ik nog iets doen aan de ventilatie box ?

De software is me redelijk duidelijk thx guys

[arnord]

Is het nu ook zo dat als ik mij sketch iets wil aanpassen (timer1,timer2,timer3) dat ik niet opnieuw hoeft te "joinen" als nieuwe sketch actief is?

Of moet ik met huidige config nog een "leave" actie doen?

[iMars]

vso schreef op zaterdag 9 december 2017 @ 23:43:
Misschien heb ik er overheen gelezen, maar wat heb ik nu nodig om dit werkend te krijgen (hw)
en moet ik nog iets doen aan de ventilatie box ?

De software is me redelijk duidelijk thx guys

• Wemos D1 mini (of een andere ESP)
• CC1101 Draadloze Module

Koppelen aan Itho is hetzelfde procedure als een originele zender koppelen

arnord schreef op zondag 10 december 2017 @ 10:50:
Is het nu ook zo dat als ik mij sketch iets wil aanpassen (timer1,timer2,timer3) dat ik niet opnieuw hoeft te "joinen" als nieuwe sketch actief is?

Of moet ik met huidige config nog een "leave" actie doen?

Timer, daar gebruik ik mijn domotica voor Ik heb nu low/mid/high, meer heb ik niet nodig

[ Voor 21% gewijzigd door iMars op 10-12-2017 17:25 ]

[arnord]

iMars schreef op zondag 10 december 2017 @ 17:24:


Timer, daar gebruik ik mijn domotica voor Ik heb nu low/mid/high, meer heb ik niet nodig

Is een keuze...ik wil ook graag leunen op timers van de Itho-box.

[iMars]

arnord schreef op zondag 10 december 2017 @ 21:54:
[...]


Is een keuze...ik wil ook graag leunen op timers van de Itho-box.

Het idee is toch mooi als je toch bezig bent met automatiseren, dat je gelijk het vocht percentage meet in de ruimte en daarop je Itho aanstuurt

[PietjePuk007]

iMars schreef op zondag 10 december 2017 @ 17:24:
[...]

• Wemos D1 mini (of een andere ESP)
• CC1101 Draadloze Module

Koppelen aan Itho is hetzelfde procedure als een originele zender koppelen

Kan je aan dezelfde Wemos ook de humidity sensor knopen?

[iMars]

PietjePuk007 schreef op maandag 11 december 2017 @ 10:57:
[...]
Kan je aan dezelfde Wemos ook de humidity sensor knopen?

Moet lukken, heb het zelf nog niet gedaan, maar er zijn genoeg pennen over...
Bij mij hangt ie nu naast de Itho, maar ik zit er over na te denken om ook een vochtsensor eraan te knopen en dan plaatsen in de badkamer, scheelt weer een extra ESP

[vso]

Hebben jullie ook kleppen in de ventilatie aangebracht ? ik denk hierbij aan het gericht(er) ventileren ..

zo ja welke units en hoe stuur je die aan ? of moet ik een ander topic ff kijken ?

[ Voor 28% gewijzigd door vso op 11-12-2017 16:07 ]

[Ierlandfan]

Aansturing kan op basis van hetzelfde protocol. Itho heeft ze in hun assortiment.

Deze gebruik ik:

https://www.google.nl/search?q=daalderop+klep+868mhz&rlz=1C1GCEA_enNL757NL758&source=lnms&tbm=shop&sa=X&ved=0ahUKEwj8qa-poILYAhUGD8AKHRtgAW8Q_AUICigB&biw=2133&bih=1054#spd=6293987100040426846

[Ierlandfan]

Welke test kan ik nog meer proberen.

Ik heb: oude cc1101 en nieuw bestelde geprobeerd
Ik heb Nodemcu en Wemos D1 Mini (meerdere) geprobeerd
Ik heb talloze codes en de originele van SuperSjimmie (met // voor testcreatemessage weggehaald)
Ik heb opnieuw gesoldeerd
Ik heb meerde soorten (werkende) USB kabels geprobeerd
Ik heb Linux Server en Windows laptop geprobeerd.
Ik kan mijn Raspberry nog proberen (...)
Ik heb de batterij vervangen in de Itho afstandsbediening
Ik heb de draadjes ingekort tot 4 en zelf 2 centimeter.
Ik heb meerdere baudrates geprobeer d(9600 en 115200)
Op de serial monitor.....niets wat op ontvangen lijkt. Het ontvangen wil gewoon niet werken.
Wat zie ik over het hoofd..

Itho remote is een (Volgens de PCB) CP5 94V-0
16872
HCCP2013

Achterop: RF Trans Auto 1251 H15/V10

Het enige wat ik nog kan verzinnen is een nieuwe batch (non-cloned voor de zekerheid) ESP8226'jes te proberen...Weet iemand een adresje in Nederland?

[arnord]

opencircuit.nl naar mij weten de orginele Wemos D1 mini.

Ierlandfan schreef op dinsdag 12 december 2017 @ 23:40:
Welke test kan ik nog meer proberen.

Ik heb: oude cc1101 en nieuw bestelde geprobeerd
Ik heb Nodemcu en Wemos D1 Mini (meerdere) geprobeerd
Ik heb talloze codes en de originele van SuperSjimmie (met // voor testcreatemessage weggehaald)
Ik heb opnieuw gesoldeerd
Ik heb meerde soorten (werkende) USB kabels geprobeerd
Ik heb Linux Server en Windows laptop geprobeerd.
Ik kan mijn Raspberry nog proberen (...)
Ik heb de batterij vervangen in de Itho afstandsbediening
Ik heb de draadjes ingekort tot 4 en zelf 2 centimeter.
Ik heb meerdere baudrates geprobeer d(9600 en 115200)
Op de serial monitor.....niets wat op ontvangen lijkt. Het ontvangen wil gewoon niet werken.
Wat zie ik over het hoofd..

Itho remote is een (Volgens de PCB) CP5 94V-0
16872
HCCP2013

Achterop: RF Trans Auto 1251 H15/V10

Het enige wat ik nog kan verzinnen is een nieuwe batch (non-cloned voor de zekerheid) ESP8226'jes te proberen...Weet iemand een adresje in Nederland?

[balk]

vso schreef op maandag 11 december 2017 @ 16:07:
Hebben jullie ook kleppen in de ventilatie aangebracht ? ik denk hierbij aan het gericht(er) ventileren ..

zo ja welke units en hoe stuur je die aan ? of moet ik een ander topic ff kijken ?

Ik heb deze in bestelling, met deze Servo. Schakelen wil ik gaan doen met een Sonoff dual.

[vso]

balk schreef op woensdag 13 december 2017 @ 22:57:
[...]


Ik heb deze in bestelling, met deze Servo. Schakelen wil ik gaan doen met een Sonoff dual.

Vind het geheel wel erg "duur" 20,- + 100,- ik zie dit niet terug verdient worden (direct) zijn er wat goedkopere oplossingen denk je ?

[iMars]

Ierlandfan schreef op dinsdag 12 december 2017 @ 23:40:
Welke test kan ik nog meer proberen.

Ik heb: oude cc1101 en nieuw bestelde geprobeerd
Ik heb Nodemcu en Wemos D1 Mini (meerdere) geprobeerd
Ik heb talloze codes en de originele van SuperSjimmie (met // voor testcreatemessage weggehaald)
Ik heb opnieuw gesoldeerd
Ik heb meerde soorten (werkende) USB kabels geprobeerd
Ik heb Linux Server en Windows laptop geprobeerd.
Ik kan mijn Raspberry nog proberen (...)
Ik heb de batterij vervangen in de Itho afstandsbediening
Ik heb de draadjes ingekort tot 4 en zelf 2 centimeter.
Ik heb meerdere baudrates geprobeer d(9600 en 115200)
Op de serial monitor.....niets wat op ontvangen lijkt. Het ontvangen wil gewoon niet werken.
Wat zie ik over het hoofd..

Itho remote is een (Volgens de PCB) CP5 94V-0
16872
HCCP2013

Achterop: RF Trans Auto 1251 H15/V10

Het enige wat ik nog kan verzinnen is een nieuwe batch (non-cloned voor de zekerheid) ESP8226'jes te proberen...Weet iemand een adresje in Nederland?

Als je in de buurt van Zoetermeer woont, wil/kan ik je wel helpen

[balk]

vso schreef op woensdag 13 december 2017 @ 23:24:
[...]

Vind het geheel wel erg "duur" 20,- + 100,- ik zie dit niet terug verdient worden (direct) zijn er wat goedkopere oplossingen denk je ?

Prijzig? Yep. Maar dit is nu eenmaal betrouwbaarder dan een knutseloplossing met terugslagklep en een servotje. Itho heeft ook een klep en die is volgens mij rond de €75.

Terugverdientijd is niet van toepassing, ik wil de ventilatie stoppen op de kinderkamers wanneer de douche aan staat vanwege geluid en capaciteit.

[vso]

balk schreef op donderdag 14 december 2017 @ 09:49:
[...]

Prijzig? Yep. Maar dit is nu eenmaal betrouwbaarder dan een knutseloplossing met terugslagklep en een servotje. Itho heeft ook een klep en die is volgens mij rond de €75.

Terugverdientijd is niet van toepassing, ik wil de ventilatie stoppen op de kinderkamers wanneer de douche aan staat vanwege geluid en capaciteit.

Nu ik vraag me af of het "betrouwbaarder" is ..

fyi denk niet dat je het 1,2,3 zelf bouwd .. maar een vraag prijs van 40,- lijkt mij stukken reeler . tis lucht wat je verplaatst niet vloeistof met 60bar oid ..

[ Voor 14% gewijzigd door vso op 14-12-2017 10:01 ]

[balk]

vso schreef op donderdag 14 december 2017 @ 09:59:
[...]

Nu ik vraag me af of het "betrouwbaarder" is ..

fyi denk niet dat je het 1,2,3 zelf bouwd .. maar een vraag prijs van 40,- lijkt mij stukken reeler . tis lucht wat je verplaatst niet vloeistof met 60bar oid ..

Helemaal waar maar ik had een meevallertje met cryptos en geen zin om te knutselen dus ik dacht: vooruit!

Overigens, qua zelfbouw zou dit nog kunnen

[vso]

balk schreef op donderdag 14 december 2017 @ 20:08:
[...]

Helemaal waar maar ik had een meevallertje met cryptos en geen zin om te knutselen dus ik dacht: vooruit!

Overigens, qua zelfbouw zou dit nog kunnen

Hey top man, die had ik nog niet gespot ben je zeer dankbaar .. ik had niet verwacht dat zo'n klein ding dat kan doen.. had zelf wat sterkers in gedachten ..

[Ierlandfan]

Inmiddels een officiele / originele NodeMCU (V3) aangesloten. Nog steeds geen pakketjes die ontvangen worden. Ook via de rcvonly versie die hier ergens in het topic rondzwerft geen ontvangst. Ik heb een dump gemaakt van wat de remote uitstuurt via RTLSDR. Misschien dat ik daar iets uit kan halen.

[Ierlandfan]

Is er een versie van de sketch die laat zien wat er binnenkomt? Ik probeer te achterhalen wat (en of) de CC1101 iets ontvangt. Ik doe hiermee op "Laat gewoon alle pakketten zien". Ik kan niet heel duidelijk achterhalen in de code waar dat zit. Het lijkt wel direct een message1 te "expecten" maar als die nou eens anders is in mijn remote doet ie het lijkt mij ook niet. Zenden werkt prima. Verander ik 172 naar 170 werkt het zenden niet dus dat lijkt hetzelfde.

[rorie]

Jammer om te lezen dat het nog steeds niet werkt, kijk even naar de post van jvandemast op woensdag 11 oktober 2017 om 12:54. Voor zover ik dat kan bepalen post hij hier wat C++ code om te laten zien wat er nou precies binnenkomt.

Ierlandfan schreef op woensdag 20 december 2017 @ 17:42:
Is er een versie van de sketch die laat zien wat er binnenkomt? Ik probeer te achterhalen wat (en of) de CC1101 iets ontvangt. Ik doe hiermee op "Laat gewoon alle pakketten zien". Ik kan niet heel duidelijk achterhalen in de code waar dat zit. Het lijkt wel direct een message1 te "expecten" maar als die nou eens anders is in mijn remote doet ie het lijkt mij ook niet. Zenden werkt prima. Verander ik 172 naar 170 werkt het zenden niet dus dat lijkt hetzelfde.

[Ierlandfan]

code:

Serial output met ingekluste debug:

setup begin

CC1101_PARTNUM 0
CC1101_VERSION 20 //In de code staat hierbij cc1101=4
CC1101_MARCSTATE 1

De NodeMCU en de CC1101 lijken elkaar te vinden.

code:

ESP8266 defined.

SS: 15
PIN_SPI_SS: 15
MISO: 12
PIN_SPI_MISO: 12
MOSI: 13
PIN_SPI_MOSI: 13
SCK: 14
PIN_SPI_SCK : 14

Ziet er ook goed uit.

code:

setup done

sending join...
Used deviceId 1: 51 83 51 43 84 204 
Used deviceId 2: 101 89 154 153 170 105 154 86 
send
sending join done.
join command sent

starting InitReceive in loop
Expecting MessageStart, - inMessage1 15

MessageStart wordt niet ontvangen.

Blijft over of de CC1101 uberhaupt iets binnenkrijgt.
In de loop komt hij ook niet verder als

Serial.print("starting InitReceive in loop\n");
Daaronder volgt:

while (1==1) {
if (rf.checkForNewPacket())
{
Serial.print("Do we ever get here?");

en die zie ik niet voorbij komen dus moet ik nog verder gaan kijken of de CC1101 zowiezo wel zijn werk doet. Nog maar even wat code gaan uitvogelen.

[jodur]

Heb de orginele code van super sjimmie voor een WEMOS D1 mini V3.0.0 en kom in een reboot cyclus terrecht. (door een soft Watch dog timer?).
Het maakt niet uit of de C1101 is aangesloten of niet.
Ik heb het ook op een andere Wemos D1 mini geprobeerd, waar hetzelfde probleem aanwezig is.
ESP easy en Micropython draait prima op deze WEMODS D1!

Dezelfde code van supersjimme in een Node MCU V3 draait zonder problemen??

Iemand hier een mogelijke verklaring voor?

Serial monitor output:


⸮setup begin
setup done
sending join...
send

Soft WDT reset

ctx: cont
sp: 3ffef480 end: 3ffef7a0 offset: 01b0

>>>stack>>>
3ffef630: feefeffe feefeffe feefeffe feefeffe
3ffef640: 3ffee5ac 000000f5 3ffee67c 40202218
3ffef650: 3ffee5ac 3ffef6f9 00000035 402021ad
3ffef660: 000000ff 000000f5 000000ff 402022d4
3ffef670: 00000016 0000001f 3ffee5ac 40202522
3ffef680: 3ffee5ac 3ffee5ac 00000028 00000000
3ffef690: 00000003 00000028 3ffee5ac 00000000
3ffef6a0: 00000003 00000028 3ffee5ac 40203558
3ffef6b0: aaaaaa48 aaaaaaaa b300feab 952aab2a
3ffef6c0: 9a59659a 9a69aa99 69a55556 a55aaa5a
3ffef6d0: 556a59a5 96596695 5965a5aa 69aa999a
3ffef6e0: a555569a 6a565969 9a596595 9a69aa99
3ffef6f0: aaa99a56 aaaaaaca aaaa13aa 5333adaa
3ffef700: cc542b33 5455abaa abaab4ca 40203f55
3ffef710: 40101180 0000000e 3ffe849a 3ffee774
3ffef720: 3fffdad0 0000000f 3ffee750 40203a65
3ffef730: 3ffe8738 00000000 3ffee750 40203a65
3ffef740: 3ffe848c 00000000 3ffee750 40203a90
3ffef750: 3ffe84bc 00000000 3ffee750 3ffee774
3ffef760: 3fffdad0 00000000 3ffee750 40201d38
3ffef770: 3fffdad0 00000000 3ffee750 40201d95
3ffef780: feefeffe feefeffe 3ffee76c 40203cf0
3ffef790: feefeffe feefeffe 3ffee780 40100114
<<<stack<<<

ets Jan 8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 1384, room 16
tail 8
chksum 0x2d
csum 0x2d
v09f0c112
~ld

[sjimmie]

Even een paar snelle reacties.

@jodur er zijn meer gevallen van een niet werkende wemos. Een wdt gebeurt ondermeer als de esp en de cc1101 niet goed communiceren. Ik heb geen wemos (en geen tijd) om uit te zoeken waarom dat niet werkt.

@Ierlandfan is je cc1101 echt een 868MHz versie? En werkt verzenden wel (check dat even met je rtl-sdr)?

@arnord je kan de code (jouw eigen .ino) aanpassen zoveel je wilt, als je maar niets verandert aan die reeksen met codes in de library zelf. de library gedraagt zich altijd als dezelfde remote, die ooit eens is gekloond.

[jodur]

Na wat debuggen heb ik achterhaald waar hij blijft hangen, waardoor de WDT ingrijpt!

In CC1101.cpp:

in de method: bool CC1101::sendData(CC1101Packet *packet)

Onderstaande loop veroorzaakt de WDT! Hij wacht tot alles verzonden is.

Is het nodig dat de CC1101 en ESP8266 elkaar moeten zien?, want bij de NodeMCU hoeft dat ook niet.

//wait until transmission is finished (TXOFF_MODE is expected to be set to 0/IDLE or TXFIFO_UNDERFLOW)
do
{
MarcState = (readRegisterWithSyncProblem(CC1101_MARCSTATE, CC1101_STATUS_REGISTER) & CC1101_BITS_MARCSTATE);
if (MarcState == CC1101_MARCSTATE_TXFIFO_UNDERFLOW) Serial.print("TXFIFO_UNDERFLOW occured in sendData() \n");
}
while((MarcState != CC1101_MARCSTATE_IDLE) && (MarcState != CC1101_MARCSTATE_TXFIFO_UNDERFLOW));

[sjimmie]

rorie schreef op zondag 26 november 2017 @ 14:12:
Zelf stuur ik ook mijn Itho eco fan aan met een NodeMCU ESP8266 met daarop aangesloten een CC1101 module. Ook lees ik de stand van mijn twee losse handzenders uit en toon ik die in mijn zelfgemaakte web intetrface. Zo kan ik bijvoorbeeld zien dan mijn Itho eco fan vanuit de wc op stand 3 is gezet en zet mijn ESP8266 deze na 10 minuten automatisch weer uit.

Hiervoor heb ik de volgende aanpassingen gedaan aan de C++ code:

Toevoeging onderaan IthoCC1101.cpp:

code:

bool IthoCC1101::checkID(const uint8_t *id)
{
    for (uint8_t i=0; i<8;i++)
        if (id[i] != inIthoPacket.deviceId[i])
            return false;
    return true;
}

String IthoCC1101::getLastIDstr() {
    String str;
    for (uint8_t i=0; i<8;i++) {
        str += String(inIthoPacket.deviceId[i], HEX);
        if (i<7) str += "-";
    }
    return str;
}

Toevoeging aan IthoCC1101.h in de sectie 'public:':

code:

bool checkID(const uint8_t *id);
String getLastIDstr();

Met bijv String myID = rf.getLastIDstr() krijg je het ID van de laatst ingedrukte knop terug.

Dat lijkt wel een beetje op wat ik er sinds een jaartje ofzo in heb zitten:

C++:

bool IthoCC1101::checkID(const uint8_t *id)
{
    for (uint8_t i=0; i<8;i++)
        if (id[i] != inIthoPacket.deviceId[i])
            return false;
    return true;
}

String IthoCC1101::getLastIDstr() {
    String str;
    for (uint8_t i=0; i<8;i++) {
        str += String(inIthoPacket.deviceId[i], HEX);
        if (i<7) str += "-";
    }
    return str;
}

[sjimmie]

jodur schreef op woensdag 3 januari 2018 @ 14:09:
Na wat debuggen heb ik achterhaald waar hij blijft hangen, waardoor de WDT ingrijpt!

In CC1101.cpp:

in de method: bool CC1101::sendData(CC1101Packet *packet)

Onderstaande loop veroorzaakt de WDT! Hij wacht tot alles verzonden is.

Is het nodig dat de CC1101 en ESP8266 elkaar moeten zien?, want bij de NodeMCU hoeft dat ook niet.

//wait until transmission is finished (TXOFF_MODE is expected to be set to 0/IDLE or TXFIFO_UNDERFLOW)
do
{
MarcState = (readRegisterWithSyncProblem(CC1101_MARCSTATE, CC1101_STATUS_REGISTER) & CC1101_BITS_MARCSTATE);
if (MarcState == CC1101_MARCSTATE_TXFIFO_UNDERFLOW) Serial.print("TXFIFO_UNDERFLOW occured in sendData() \n");
}
while((MarcState != CC1101_MARCSTATE_IDLE) && (MarcState != CC1101_MARCSTATE_TXFIFO_UNDERFLOW));

Als hij in die loop op een WDT uitkomt dan betekent dat dat hij waarschijnlijk niets verzendt.
Want normaliter is het in een fractie van een seconde klaar en zal er echt geen wdt reset optreden.

[jodur]

@sjimmie

De Marcstate = 0x13 => CC1101_MARCSTATE_TX uit C1101.h in de loop, dus het klopt dat hij hierin blijft hangen.

Verklaard voor mij nog steeds niet waarom hij dit bij een Node MCU V3 niet in blijft hangen terwijl er geen c1101 is aangesloten.

p.s. overigens werkt jouw code prima op de Node MCU V3, ik kan de codes van mijn RF remote ontvangen.

[sjimmie]

jodur schreef op woensdag 3 januari 2018 @ 14:47:
@sjimmie

De Marcstate = 0x13 => CC1101_MARCSTATE_TX uit C1101.h in de loop, dus het klopt dat hij hierin blijft hangen.

Verklaard voor mij nog steeds niet waarom hij dit bij een Node MCU V3 niet in blijft hangen terwijl er geen c1101 is aangesloten.

p.s. overigens werkt jouw code prima op de Node MCU V3, ik kan de codes van mijn RF remote ontvangen.

Het zal volgens mij ook wel blijven werken als je dat hele do { ... } while ... block eruit haalt en het vervangt door een delay(). Dit blokje voorkomt dat "te snel" finishTransfer wordt aangeroepen. Hoe lang je delay dan moet zijn is een beetje gokken, een paar msec moet al voldoen. (los van of het netjes is)
Je zou zelfs de while wat netter kunnen maken door er een timeout in te bouwen.
Of, maar dat lost jouw probleem niet op, een yield() in de loop zetten. Dat voorkomt een wdt reset maar als de marcstate niet goed wordt dan zit je nog vast in de loop.

Mijn eigen ervaring is een wdt reset als de boel niet goed is aangesloten. Waarom er bij jou geen wdt reset optreedt weeet ik dan ook niet. Maar dat vind ik ook niet heel relevant.

[sjimmie]

Hmm, wat ik nu ineens zie...
De wemos D1 heeft soms(?) geen metalen shield over de esp chip? Ik vermoed dat de chip daardoor last krijgt van de, best wel krachtige, 868MHz TX en dat daarom sommige mensen met een wemos een reset krijgen.

[jodur]

sjimmie schreef op woensdag 3 januari 2018 @ 15:00:
[...]

Het zal volgens mij ook wel blijven werken als je dat hele do { ... } while ... block eruit haalt en het vervangt door een delay(). Dit blokje voorkomt dat "te snel" finishTransfer wordt aangeroepen. Hoe lang je delay dan moet zijn is een beetje gokken, een paar msec moet al voldoen. (los van of het netjes is)
Je zou zelfs de while wat netter kunnen maken door er een timeout in te bouwen.
Of, maar dat lost jouw probleem niet op, een yield() in de loop zetten. Dat voorkomt een wdt reset maar als de marcstate niet goed wordt dan zit je nog vast in de loop.

Mijn eigen ervaring is een wdt reset als de boel niet goed is aangesloten. Waarom er bij jou geen wdt reset optreedt weeet ik dan ook niet. Maar dat vind ik ook niet heel relevant.

Heb de C1101 nu opnieuw aangesloten en werkt het !

[jodur]

sjimmie schreef op woensdag 11 oktober 2017 @ 12:54:
[...]

Oef, in grove stappen...
Een boolean dit bijhoudt of er een packet is ontvangen:

C++:

bool ITHOhasPacket = false;

Dan een interrupt aan de cc1101 interrupt pin:

C++:

void setup() {
//...
  attachInterrupt(ITHO_IRQ_PIN, ITHOinterrupt, RISING);
}

In de loop kijk ik dan regelmatig of de boolean true is geworden:

C++:

void loop() {
// do whatever you want
  if (ITHOhasPacket) {
    ITHOshowPacket();
}

Omdat de cc1101 interrupt pin al hoog wordt zodra er een bitje binnenkomt heb ik een korte vertraging voordat het uitlezen wordt gestart:

C++:

inline static void ICACHE_RAM_ATTR  __attribute__((always_inline)) ITHOinterrupt() {
  ITHOticker.once_ms(10, ITHOcheck);
}

Dan wordt de data uitgelezen en in wat variabelen gezet(die zal je zelf even bij elkaar moeten schrapen):

C++:

void ITHOcheck() {
  if (rf.checkForNewPacket()) {
    IthoCommand cmd = rf.getLastCommand();
    if (++RFTcommandpos > 2) RFTcommandpos = 0;  // store information in next entry of ringbuffers
    RFTcommand[RFTcommandpos] = cmd;
    RFTRSSI[RFTcommandpos]    = rf.ReadRSSI();
    bool chk = rf.checkID(RFTid);
    RFTidChk[RFTcommandpos]   = chk;
    if ((cmd != IthoUnknown) && chk) {  // only act on good cmd and correct id.
      ITHOhasPacket = true;
    }
  }
}

Omdat de itho zender 3 keer hetzelfde verstuurt en die 3 niet altijd goed worden ontvangen, heb ik een controle-functie:

C++:

uint8_t findRFTlastCommand() {
  if (RFTcommand[RFTcommandpos] != IthoUnknown)               return RFTcommandpos;//RFTcommand[RFTcommandpos];
  if ((RFTcommandpos == 0) && (RFTcommand[2] != IthoUnknown)) return 2;//RFTcommand[2];
  if ((RFTcommandpos == 0) && (RFTcommand[1] != IthoUnknown)) return 1;//RFTcommand[1];
  if ((RFTcommandpos == 1) && (RFTcommand[0] != IthoUnknown)) return 0;//RFTcommand[0];
  if ((RFTcommandpos == 1) && (RFTcommand[2] != IthoUnknown)) return 2;//RFTcommand[2];
  if ((RFTcommandpos == 2) && (RFTcommand[1] != IthoUnknown)) return 1;//RFTcommand[1];
  if ((RFTcommandpos == 2) && (RFTcommand[0] != IthoUnknown)) return 0;//RFTcommand[0];
  return -1;
}

En een functie om de ontvangen code weer te geven:

C++:

void ITHOshowPacket()    {
  ITHOhasPacket = false;
  uint8_t goodpos = findRFTlastCommand();
  if (goodpos != -1)  RFTlastCommand = RFTcommand[goodpos];
  else                RFTlastCommand = IthoUnknown;
  //show command
  Serial.print(F("RFT Current Pos: "));
  Serial.print(RFTcommandpos);
  Serial.print(F(", Good Pos: "));
  Serial.println(goodpos);
  Serial.print(F("Stored 3 commands: "));
  Serial.print(RFTcommand[0]);
  Serial.print(F(" "));
  Serial.print(RFTcommand[1]);
  Serial.print(F(" "));
  Serial.print(RFTcommand[2]);
  Serial.print(F(" / Stored 3 RSSI's:     "));
  Serial.print(RFTRSSI[0]);
  Serial.print(F(" "));
  Serial.print(RFTRSSI[1]);
  Serial.print(F(" "));
  Serial.print(RFTRSSI[2]);
  Serial.print(F(" / Stored 3 ID checks: "));
  Serial.print(RFTidChk[0]);
  Serial.print(F(" "));
  Serial.print(RFTidChk[1]);
  Serial.print(F(" "));
  Serial.print(RFTidChk[2]);
  Serial.print(F(" / Last ID: "));
  Serial.print(rf.getLastIDstr());

  Serial.print(F(" / Command = "));
  switch (RFTlastCommand) {
    case IthoUnknown:
      Serial.print(F("unknown\n"));
      break;
    case IthoLow:
      Serial.print(F("low\n"));
      RFTstate = RFTlastCommand;
      break;
    case IthoMedium:
      Serial.print(F("medium\n"));
      RFTstate = RFTlastCommand;
      break;
    case IthoFull:
      Serial.print(F("full\n"));
      RFTstate = RFTlastCommand;
      break;
    case IthoTimer1:
      Serial.print(F("timer1\n"));
      RFTstate = RFTlastCommand;
      break;
    case IthoTimer2:
      Serial.print(F("timer2\n"));
      RFTstate = RFTlastCommand;
      break;
    case IthoTimer3:
      Serial.print(F("timer3\n"));
      RFTstate = RFTlastCommand;
      break;
    case IthoJoin:
      Serial.print(F("join\n"));
      break;
    case IthoLeave:
      Serial.print(F("leave\n"));
      break;
  }
}

Dat zal het ongeveer wel zijn.
Er wordt gebruikgemaakt van 3 functies die ik in de library heb zitten:
rf.checkForNewPacket()
rf.getLastCommand()
rf.checkID(RFTid)
rf.ReadRSSI()
Die staan in de volgende post.

waar is de define van ITHO_IRQ_PIN ?

[jodur]

Ik probeer het ontvangen nu ook op interrupt basis, zodat ik ook een state topic kan toevoegen aan de ESP Easy plugin zoals deze al is opgezet door @ThinkPad

Als ik de suggesties doorlees van @sjimmie is onderstaande stappen essentiel

1 : Zet de interupt aan: voor ontvangen => writeRegister(CC1101_IOCFG2 ,0x00);
2: Koppel ISR (Interrupt service routine aan Pin? ) (zie mijn vraag voor ITH_IRQ_PIN)

Gebruik je hier de GDO2 pin voor van de c1101? (wordt in orginele code van jvdmast niet aangesloten?) en moet ik deze dan op een vrije input aansluiten op de ESP8266 en is dit dan de pin die ik moet opgeven bij attachInterrupt?

[EDIT 5-01-2018]

Ben inmiddels al verder, krijg nu netjes een interrupt als er nieuwe data ontvangen is, alleen het verwerken van de packagedata gaat nog niet goed, moet nog ff verder duiken in de SPI communicatie met de CC1101

@sjimmie kan misschien nog wel een zet gebruiken in de goede richting!

[ Voor 43% gewijzigd door jodur op 05-01-2018 16:35 ]

[sjimmie]

jodur schreef op donderdag 4 januari 2018 @ 21:06:
waar is de define van ITHO_IRQ_PIN ?

Waar jij die neerzet.
Bij mij staan dergelijke #define regels bovenaan in de algehele .ino file.

C++:

#define ITHO_IRQ_PIN    D2

jodur schreef op donderdag 4 januari 2018 @ 22:59:
Ik probeer het ontvangen nu ook op interrupt basis, zodat ik ook een state topic kan toevoegen aan de ESP Easy plugin zoals deze al is opgezet door @ThinkPad

Als ik de suggesties doorlees van @sjimmie is onderstaande stappen essentiel

1 : Zet de interupt aan: voor ontvangen => writeRegister(CC1101_IOCFG2 ,0x00);
2: Koppel ISR (Interrupt service routine aan Pin? ) (zie mijn vraag voor ITH_IRQ_PIN)

Gebruik je hier de GDO2 pin voor van de c1101? (wordt in orginele code van jvdmast niet aangesloten?) en moet ik deze dan op een vrije input aansluiten op de ESP8266 en is dit dan de pin die ik moet opgeven bij attachInterrupt?

[EDIT 5-01-2018]

Ben inmiddels al verder, krijg nu netjes een interrupt als er nieuwe data ontvangen is, alleen het verwerken van de packagedata gaat nog niet goed, moet nog ff verder duiken in de SPI communicatie met de CC1101

@sjimmie kan misschien nog wel een zet gebruiken in de goede richting!

Momenteel ben ik een catch-up aan het maken om nog eens te proberen mijn ITHO van standby en de dikke Full te voorzien. In tegenstelling tot bij anderen, gaat de mijne in een soort interval ipv standby of full. Maar wellicht ondersteunt mijn fan gewoon die standen niet.

Mijn plan is om zeer binnenkort mijn laatste versie van mijn versie van de library online te zetten, waar niet alleen die standby/full zit, maar ook zaken zoals het ontvangen via een interrupt.

Maar inderdaad, hier gaat de GDO2 (cc1101 pin 6) naar een vrije pin, die dan als IRQ wordt gebruikt.

[jodur]

sjimmie schreef op vrijdag 5 januari 2018 @ 18:16:

Mijn plan is om zeer binnenkort mijn laatste versie van mijn versie van de library online te zetten, waar niet alleen die standby/full zit, maar ook zaken zoals het ontvangen via een interrupt.

Enig idee van een ETA ?

[sjimmie]

jodur schreef op vrijdag 5 januari 2018 @ 18:33:
[...]


Enig idee van een ETA ?

2018

[sjimmie]

Oke, oke... Voor wie durft, de laatste versie van de library staat op mijn github.
https://github.com/supersjimmie/IthoEcoFanRFT
Ik heb alleen nog geen nieuwe .ino om de nieuwe functionaliteiten te demo-en.
Je zal het dus voorlopig zelf moeten uitvogelen.

C++:

#define ITHO_IRQ_PIN    D2

#include <Ticker.h>

void setup(){
  attachInterrupt(ITHO_IRQ_PIN, ITHOinterrupt, RISING);
}

inline static void ICACHE_RAM_ATTR  __attribute__((always_inline)) ITHOinterrupt() {
  ITHOticker.once_ms(10, ITHOcheck);
}

void ITHOcheck() {
  if (rf.checkForNewPacket()) {
    IthoCommand cmd = rf.getLastCommand();
    if (++RFTcommandpos > 2) RFTcommandpos = 0;  // store information in next entry of ringbuffers
    RFTcommand[RFTcommandpos] = cmd;
    RFTRSSI[RFTcommandpos]    = rf.ReadRSSI();
    bool chk = rf.checkID(RFTid);
    RFTidChk[RFTcommandpos]   = chk;
    if ((cmd != IthoUnknown) && chk) {  // only act on good cmd and correct id.
      ITHOhasPacket = true;
    }
  }
}

En dan nog "a whole bunch" aan variabelen die je nog even zelf moet declareren, zoals o.a.:

C++:

IthoCommand RFTcommand[3] = {IthoUnknown, IthoUnknown, IthoUnknown};
byte RFTRSSI[3] = {0, 0, 0};
byte RFTcommandpos = 0;
IthoCommand RFTlastCommand = IthoLow;
IthoCommand RFTstate = IthoUnknown;
IthoCommand savedRFTstate = IthoUnknown;
const uint8_t RFTid[] = {106, 170, 106, 101, 154, 107, 154, 86}; // my ID
bool RFTidChk[3] = {false, false, false};

Ik gebruik de Ticker library om een korte vertraging in te bouwen tussen de interrupt en het ophalen van de gegevens. Dat is nodig omdat de interrupt al op het eerste bitje verschijnt en er dan nog even gewacht moet worden op de rest van het packet. Persoonlijk vond ik het via de Ticker elegant genoeg...

[ Voor 79% gewijzigd door sjimmie op 05-01-2018 19:04 . Reden: voorbeeldcode toegevoegd ]

[jodur]

@sjimmie bedankt voor de snelle reactie!. Zal hier mee verder gaan.

Loop zelf nu vast omdat ik conform jouw aanwijzingen alleen message2 wil ontvangen.
Ik ontvang netjes 42 bytes, alleen wordt het commando niet herkent door de commandparser.

ik vermoed dat hier dan ook een deel van de bytes/bits van message 1 in zit.
Heb al door de datasheet van de C1101 zitten lezen. In de huidige code wordt er geen gebruik gemaakt van de packet filter (alleen packet lenght filer), waardoor we b.v. een message kunnen "ignoren."

Ga nu eerst verder in jouw code "neuzen" om te kijken als ik iets wijzer word. Bevinden deel ik uiteraard weer hier op het forum.

EDIT 20:15 Het Werk met jouwe nieuw library top, bedankt

N.B. heb de code herkenbaar gemaakt conform het moeder voorbeeld in deze forum-thread
Zal jouw toevoegingen voor de juiste remote ook verder uittesten

code:

#include <SPI.h>
#include "IthoCC1101.h"
#include "IthoPacket.h"
#include <Ticker.h>

#define ITHO_IRQ_PIN D3

IthoCC1101 rf;
IthoPacket packet;
Ticker ITHOticker;

void setup(void) {
  Serial.begin(115200);
  rf.init();
  Serial.println("Init:setup done");

  //set CC1101 registers to receive
  rf.initReceive();
  //Attach GD02 to GPIO 0
  pinMode(ITHO_IRQ_PIN, INPUT);
  attachInterrupt(ITHO_IRQ_PIN, ITHOinterrupt, RISING);
}

void loop(void)
{   
  yield();
} 

void ITHOinterrupt()
{ 
    ITHOticker.once_ms(10, ITHOcheck);
}

void ITHOcheck()
  {
  if (rf.checkForNewPacket()) {
    IthoCommand cmd = rf.getLastCommand();
    //show counter
      
    //device_id
    Serial.print("device-ID remote: ");
    Serial.print(rf.getLastIDstr());
    Serial.print(" ,Command received= ");
      //show command
      switch (cmd) {
        case IthoUnknown:
          Serial.print("unknown\n");
          break;
        case IthoLow:
          Serial.print("low\n");
          break;
        case IthoMedium:
          Serial.print("medium\n");
          break;
        case IthoHigh:
         Serial.print("high\n");
          break;
        case IthoFull:
          Serial.print("full\n");
          break;
        case IthoTimer1:
          Serial.print("timer1\n");
          break;
        case IthoTimer2:
          Serial.print("timer2\n");
          break;
        case IthoTimer3:
          Serial.print("timer3\n");
          break;
        case IthoJoin:
          Serial.print("join\n");
          break;
        case IthoLeave:
          Serial.print("leave\n");
          break;
      }
    }
  }

[ Voor 61% gewijzigd door jodur op 05-01-2018 20:58 ]

[Pascal Saul]

Dus als ik het goed begrijp staat binnenkort een versie online waarmee we de status van de unit kunnen bijhouden?

Zodanig dat onze domotica weet op welke stand de unit draait en of dat nu door de ESPeasy is aangestuurd of door een handbediening maakt niet meer uit?

De Full en Stand-by stand heb ik ook nog niet eerder gezien.

Het zou helemaal mooi zijn als we ESPeasy kunnen vervangen door Tasmota ooit zodat alle ESP's hier in huis dezelfde software draaien

[sjimmie]

Pascal Saul schreef op zaterdag 6 januari 2018 @ 11:13:
Dus als ik het goed begrijp staat binnenkort een versie online waarmee we de status van de unit kunnen bijhouden?

Zie een paar berichten naar boven.

sjimmie schreef op vrijdag 5 januari 2018 @ 18:53:

Oke, oke... Voor wie durft, de laatste versie van de library staat op mijn github.
https://github.com/supersjimmie/IthoEcoFanRFT
...

[Pascal Saul]

sjimmie schreef op zaterdag 6 januari 2018 @ 12:15:
[...]

Zie een paar berichten naar boven.
[...]

Ik zie dat jodur ermee bezig is gegaan hierboven en hopelijk dat @ThinkPad dit in zijn .bin kan aanpassen

[sjimmie]

@jodur werken bij jou de standby en full ook naar behoren? want dan weet ik dat de code klopt en ik hier een issue met mijn fan zelf heb...

Ik wil binnenkort een beknopte .ino example maken waarin ook het interrupt-gedreven ontvangen werkt.
(en dus ook de ontvangen info netjes weergeeft)
Edit: ow dat heb jij al.
Edit2: ik ga wellicht nog toevoegen om de 3 verzonden packets te filteren om fout onvangen packets eruit te halen en toch de goede te zien.

[ Voor 30% gewijzigd door sjimmie op 06-01-2018 14:20 ]

[ThinkPad]

Pascal Saul schreef op zaterdag 6 januari 2018 @ 12:20:
[...]
Ik zie dat jodur ermee bezig is gegaan hierboven en hopelijk dat @ThinkPad dit in zijn .bin kan aanpassen

Helaas. Ik heb geen remotes die ik zou willen ontvangen. Ben allang blij dat het versturen werkt, dat heeft mij al meerdere weekenden gekost om via ESPEasy werkend te krijgen

[Ierlandfan]

Het werkt!! (Als in ook bij mij) Alle andere versies werkten niet en deze werkte meteen. Wow! Heel hartelijk bedankt voor de interrupt driven versie, dit was voor mij de enige die werkt! Medium, low, high, werken allemaal, (1tje wordt nog niet herkend maar is niet zo'n probleem) ik zie zelfs een aantal ander remotes voorbij komen (Of dit is mijn badkamer of Co2 meter van Itho ook) Helemaal top!

[jodur]

sjimmie schreef op zaterdag 6 januari 2018 @ 13:48:
@jodur werken bij jou de standby en full ook naar behoren? want dan weet ik dat de code klopt en ik hier een issue met mijn fan zelf heb...

Klinkt misschien raar, maar ik heb me tot op heden alleen gefocust op het ontvangen en moest me nog inleren m.b.t. ESP8266, C1101,Arduino, ontwikkelen Espeasy plugin etc. Aangezien dit een nieuwe wereld is voor mij., lag bij het inleren mijn focus de afgelopen tijd. Gezien de geluiden op het forum "geloofde" ik dat her verzenden wel werkt en daar lag niet de uitdaging. Heb veel tijd verbrand om eerst de code zelf werkend te krijgen op interrupt basis. Echter kwam jij precies op tijd met jouw nieuwe post van de library (scheelt mij weer hoop tijd)
Ben nog te "lui" geweest om m'n FAN spanningloos te maken en deze te pairen (Zit achter het knieschot waar ook troep staat en weet ook niet achter welke groep hij zit). Dit ga ik uiteraard testen (planning morgen) als dit past in de planning i.v.m. sport kinderen attention to wife.

[sjimmie]

ThinkPadd schreef op zaterdag 6 januari 2018 @ 15:00:
[...]

Helaas. Ik heb geen remotes die ik zou willen ontvangen. Ben allang blij dat het versturen werkt, dat heeft mij al meerdere weekenden gekost om via ESPEasy werkend te krijgen

Zou jij wel het zenden van de standby en full willen testen met deze bijgewerkte library?

Ierlandfan schreef op zaterdag 6 januari 2018 @ 16:24:
Het werkt!! (Als in ook bij mij) Alle andere versies werkten niet en deze werkte meteen. Wow! Heel hartelijk bedankt voor de interrupt driven versie, dit was voor mij de enige die werkt! Medium, low, high, werken allemaal, (1tje wordt nog niet herkend maar is niet zo'n probleem) ik zie zelfs een aantal ander remotes voorbij komen (Of dit is mijn badkamer of Co2 meter van Itho ook) Helemaal top!

LOL, mooie reactie!
Bedoel je dat bij jou de standby en full (ook, net als bij mij) niet werken? Ik ben nog steeds erg benieuwd of die bij andere mensen wel werken...
Dat je andere remotes voorbij ziet komen, daar had ik ook last van. In mijn .ino zit daarom een filter ingebouwd. Goed dat je het noemt want eigenlijk vind ik dat we allemaal zo'n filter moeten gebruiken om de privacy van onze buren te bewaren..

[ Voor 17% gewijzigd door sjimmie op 06-01-2018 17:17 ]

[jodur]

ThinkPadd schreef op zaterdag 6 januari 2018 @ 15:00:
[...]

Helaas. Ik heb geen remotes die ik zou willen ontvangen. Ben allang blij dat het versturen werkt, dat heeft mij al meerdere weekenden gekost om via ESPEasy werkend te krijgen

Don't worry, heb al een ESP Easy versie draaien die kan zenden en ontvangen (op interrupt basis) en gewoon gecombineerd kan worden met alle andere plugins (b.v. DHT22 voor temperatuur en vocht).

Tip: Las in de wiki van ESPEASY dat je ook rules kan toevoegen, wat dus betekend dat je b.v. je Fan kan aansturen op basis van het vochtpercentage van de DHT22. Heb dit zelf nog niet getest, want ik doe alle automation in home-assistant.

Zal eerdaags de source uploaden naar GIT-HUB en de link hier posten. Zal er ook een klant en klare binary aan toevoegen voor de "codeless people".

Voor MQTT zijn er in eerste instantie 2 topics die gepublished worden: <State> en <Timer>

De Timer is een "estimate" van de elapsed time, indien een hardwarematige timer van de Fan is gestart.

State Topics:

code:

State 0: => Standby?
State 1: => Low
State 2: => Medium
State 3: => High
State 4: => Full ?
State 10:=> Timer1
State 20: => Timer 2
State 30: =>Timer 3

Ik moet de code nog bijschaven, zoals:
- MQTT transmit reductie (Wordt nu cyclisch data verstuurd, met dezelfde info, wil dit reduceren)
- configuratie interrupt pin
- configuratie bekende remotes (zodat alleen op bekende remote wordt gereageerd)
- MQTT Topic toevoegen: last_controlled_by <id-remote>

@sjimmie In jouw code filter je maar op één remote toch? Dit zal een array van remotes moeten zijn want er zijn natuurlijk mensen met meerdere remotes voor één Fan (b.v. Keuken, Badkamer en WC?)

Met name m.b.t. laatste punt zit nog wat uitzoekwerk, omdat er nog weinig voorbeelden zijn met vrije "String velden" die worden opgeslagen, zodat niet naar elke reboot, dit opnieuw moet worden ingevuld.
Ook het aantal remotes is een variabele dit configureerbaar moet zijn
Helaas kent Arduino en dus ESPEASY geen DWORD (64 bits) anders hadden we het ID eenvoudig kunnen opslaan.
Bij ESPEASY moet alles configureerbaar zijn.

@ThinkPadd Ik heb uiteraard jouw plugin als opstapje gebruikt en zal dit ook in de bron vermelden!

Alle hulde gaat naar @sjimmie en voorgangers, b.v. diegene die met een RFSniffer en/of logic analyzer het protocol hebben ontrafeld.

[ Voor 10% gewijzigd door jodur op 06-01-2018 17:55 ]

[ThinkPad]

@jodur Top!

Wat is trouwens het verschil tussen 'full' en 'high'? En 'standby' en 'low'?
Ik heb geen remote, dus ken alleen de low/medium/high van de 3-standenschakelaar.

[Speedy-Andre]

Stand-by is de laagst mogelijke stand, die kan je ook met een potmeter op de Itho zo instellen als je wil weten hoe dat in de praktijk is.
Full is de maximale snelheid die je met de andere potmeter kan simuleren.
Volgens mij reageert stand 2 hier ook op, die verschuift mee.
Bij mij komt het full commando niet door maar stand-by wel en die wilde ik graag gebruiken als ik weg ben
Als er een .bin komt met de mogelijkheid van ontvangen signalen zien dan lijkt me dat leuk,ik heb andere apparaten op 868MHz die ik dan misschien kan zien.

[sjimmie]

Zojuist heb ik een nieuwe versie van de .ino online gezet op github.
Daarin zit ondermeer de standby en full, alsmede het ontvangen obv interrupt.
Let wel op, er zit een check in op Device ID. Je zal hiermee alleen zien wat door jouw eigen remote wordt verzonden. Dit vind ik nodig om de privacy van de buren te respecteren, en zal vooral praktisch zijn om te voorkomen dat jouw esp8266 denkt dat je op een knop hebt gedrukt terwijl dat bij de buren was.
Je bent uiteraard vrij om die check er, tijdelijk, uit te halen. Zonder de check kan je alles zien, maar zal het bv ook werken als je je eigen remote ID (nog) niet weet.

C++:

    bool chk = rf.checkID(RFTid);

ThinkPadd schreef op zaterdag 6 januari 2018 @ 17:41:
Wat is trouwens het verschil tussen 'full' en 'high'? En 'standby' en 'low'?
Ik heb geen remote, dus ken alleen de low/medium/high van de 3-standenschakelaar.

De nieuwe Full is nog hoger dan de oude Full (die is vervangen door High).
De Standby is nog lager dan de Low.
Helaas gaan die beide bij mijzelf nog niet goed, in plaats daarvan ontstaat er een soort interval-modus waarbij de fan iedere 15sec heel even aanslaat en dan weer terugvalt.

jodur schreef op zaterdag 6 januari 2018 @ 17:38:
@sjimmie In jouw code filter je maar op één remote toch? Dit zal een array van remotes moeten zijn want er zijn natuurlijk mensen met meerdere remotes voor één Fan (b.v. Keuken, Badkamer en WC?)

Niets moet en alles mag! Voor de meeste mensen zal zo'n kleine aanpassing niet lastig zijn om zelf te doen indien nodig. Voor een example is 1 een stuk handiger om te snappen.

jodur schreef op zaterdag 6 januari 2018 @ 17:38:
Alle hulde gaat naar @sjimmie en voorgangers, b.v. diegene die met een RFSniffer en/of logic analyzer het protocol hebben ontrafeld.

Een klein beetje historie.
De hele uitzoekerij is gedaan door:
Rogier: https://www.progz.nl/home...-itho-cve-eco-rft-part-1/
Github/Klusjesman: https://github.com/Klusjesman/IthoEcoFanRFT
Toen daar al heel veel werk was verricht ben ik mee gaan doen met het sniffen mbv een RTL-SDR en daarna vele duizenden bitjes tellen. Uiteindelijk is daaruit een stuk code gekomen die ik heb aangepast om te werken op een esp8266.

[ Voor 10% gewijzigd door sjimmie op 06-01-2018 18:37 ]

[jodur]

@sjimmie

Nu is in de library een fixed ID (8-bytes) opgenomen, dus als mijn buurman b.v. ook een tweaker is en dit topic volgt en ook het ID niet veranderd in de code, zal hij theoretisch mijn Fan kunnen sturen.

Zij er resticties t.a.v. het ID wat we kunnen instellen? (zijn alle nummer toegestaan?)
Ik zou het liefst het MAC-ID (6 bytes) van de ESP8266 Wifi chip willen gebruiken in het ID wat we verzenden.

Daarmee hebben we voor elke device (onafhankelijk v.d software) een unieke code.

[sjimmie]

jodur schreef op zaterdag 6 januari 2018 @ 21:23:
@sjimmie

Nu is in de library een fixed ID (8-bytes) opgenomen, dus als mijn buurman b.v. ook een tweaker is en dit topic volgt en ook het ID niet veranderd in de code, zal hij theoretisch mijn Fan kunnen sturen.

Zij er resticties t.a.v. het ID wat we kunnen instellen? (zijn alle nummer toegestaan?)
Ik zou het liefst het MAC-ID (6 bytes) van de ESP8266 Wifi chip willen gebruiken in het ID wat we verzenden.

Daarmee hebben we voor elke device (onafhankelijk v.d software) een unieke code.

Goed punt, ooit eens kort ter sprake geweest maar nooit veel mee gedaan.
Ik weet wel dat er een paar wazige dingen in de codering zitten die niet met ieder ID werkten. (in die calculate-byte functies). Ze werkten met dit ID maar we kregen het toen niet mel elk ander ID werkend. Dat is precies de reden dat gekozen is voor deze hardcoded IDs van Klusjesman. Wellicht is een kleine variatie ergens in een algemeen byte voldoende, maar daar is nooit meer mee getest.

Edit, het viel mij wel eens op dat de gebruikte bitreeksen die de bytes vormen bepaalde patronen volgen, ik verwacht dat daardoor sowieso niet alle waardes zullen werken. Hoe dat zat kan ik niet meer terugzoeken omdat ik inmiddels mijn gesnifte bitpatronen kwijt ben, en ik dat echt niet meer opnieuw wil doen.

Je zou het kunnen uitproberen, wijzig ergens een bit in de IDs op een punt waar de calculate functies niets mee doen, join opnieuw en check de codes.

Edit, wat ik bedoel met niet alle waards zullen werken, is dat het opvallend is dat bijna alle bytes tamelijk hoge waardes hebben. En ik meen me te herinneren dat er bv nooit meer dan 2 dezelfde bits aaneensluitend in zitten ofzo.

[ Voor 18% gewijzigd door sjimmie op 06-01-2018 21:55 ]

[jodur]

@sjimmie

Ik heb zojuist snel de volgende test gedaan. Heb de ID van mijn afstandbediening die reeds al gepaired is met mijn Fan als ID in de code gezet, om te kijken of hij dan op mijn commando's reageert.
Er gebeurd niets?? Dit is niet wat ik zou verwachten.

Kruip vanavond dan toch maar achter het knieshot, om te pairen me de orginele ID in de code!

[sjimmie]

jodur schreef op zondag 7 januari 2018 @ 16:40:
@sjimmie
Heb de ID van mijn afstandbediening die reeds al gepaired is met mijn Fan als ID in de code gezet.
Er gebeurd niets?? Dit is niet wat ik zou verwachten.

Yep, dat is dus wat wij destijds ook merkten.
Er zit blijkbaar meer codering achter waardoor een low met jouw ID toch weer anders is, enz.
Daarom dus voor het gemak 1 fixed ID, anders hadden we het ID wel een var gemaakt.
Maar ik vermoed dat we wel zouden kunnen varieren in een paar bitjes waarmee het wel blijft werken, maar dan moeten we daarmee experimenteren en vervolgens moet "iedereen" een beetje eigen variatie maken in geval van buren met eenzelfde itho-esp combi.

[jodur]

@sjimmie

Hierbij de "confirm" van mijn zijde dat de standy en Full commando's bij mij werken.

Ik kan geen verschil merken tussen Low en standby, maar waarschijnlijk hebben ze de potmeter helemaal terug gedraaid diebij de stand low hoort. (Heb de IHTO box alleen voor ventilatie badkamer)

Tussen High en Full zit nog wel een duidelijk verschil.

Het experimenteren met bitjes "klinkt" mij teveel als trial en error. Jammer dat nog niet exact het protocol "ontrafelt" is. Maar ben blij en heb resprect dat jullie al zover zijn gekomen.

Mijn buren zijn geen "tweakers",dus de kans dat hun met deze code hun Fan gaan sturen is erg klein.

[ Voor 8% gewijzigd door jodur op 07-01-2018 20:48 ]

[sjimmie]

jodur schreef op zondag 7 januari 2018 @ 20:36:
@sjimmie

Hierbij de "confirm" van mijn zijde dat de standy en Full commando's bij mij werken.

Dat is goed nieuws... voor jou!
Dan ligt het dus aan mijn ecofan zelf, dat die niet in de standby of full stand wil gaan, dus slecht nieuws voor mij.

Zou jij, als je weer eens achter dat schot komt bij jouw fan, wat exacte typenummers enzo willen noteren?
Wellicht is te ontdekken waar het verschil zit.

[jodur]

Allen, hierbij de first release van mijn ESP Easy plugin die ook commandos "ontvangt" van bestaande remotes.

Lees eerst de readme.md door voor je vragen stelt.

https://github.com/jodur/ESPEASY_Plugin_ITHO

Ik heb heb nog geen duurtesten gedaan en heb hem maar kunnen testen met 1 RF remote, maar dat kan niet het probleem zijn.

N.B. er is ook een binary toegevoegd die je direct kan flashen!

Hoor graag jullie bevindingen!

[Pascal Saul]

jodur schreef op maandag 8 januari 2018 @ 22:37:
Allen, hierbij de first release van mijn ESP Easy plugin die ook commandos "ontvangt" van bestaande remotes.

Lees eerst de readme.md door voor je vragen stelt.

https://github.com/jodur/ESPEASY_Plugin_ITHO

Ik heb heb nog geen duurtesten gedaan en heb hem maar kunnen testen met 1 RF remote, maar dat kan niet het probleem zijn.

N.B. er is ook een binary toegevoegd die je direct kan flashen!

Hoor graag jullie bevindingen!

Goed bezig maar is deze ook al MQTT proof want dat haal ik niet uit de code? Ja sorry, ik ben verwend met MQTT

[jodur]

Pascal Saul schreef op maandag 8 januari 2018 @ 23:27:
[...]


Goed bezig maar is deze ook al MQTT proof want dat haal ik niet uit de code? Ja sorry, ik ben verwend met MQTT

Uiteraard, ik gebruik zelf ook de MQTT. Dat je dit in de code niet herkent heeft te maken dat het een plugin is. De afhandeling van MQTT gebeurd door code die niet in de plugin staat maar in de basiscode van ESPEasy.

Default topics als je openHAB MQTT als controller instelt:

published vars:

<systeem naam>/<task naam>/State
<systeem naam>/<task naam>/Timer

Systeem naam en task naam kan je zelf configureren

subscribed vars;

<systeem naam>/cmd <commando>

b.v. dus ESP_Easy/cmd "State 1" of ESP_Easy/cmd "State,1" (spatie of komma)

Het topic van de subscribed vars staan mij nog niet aan. Het commando en waarde van het commando zitten nu beide in de payload.

Een volgende versie zal dit worden als dat lukt binnen ESP_Easy:
<systeem naam>/<task naam>/cmd/<commando> <payload>

Waarbij de payload dan alleen de variabele is voor het commando.

[ Voor 23% gewijzigd door jodur op 09-01-2018 15:24 ]

[demanditho]

Heeft er iemand kunnen koppelen dan met een demand of quality flow systeem? Deze werken met de zenders van type 536-0146

[sjimmie]

demanditho schreef op dinsdag 9 januari 2018 @ 16:56:
Heeft er iemand kunnen koppelen dan met een demand of quality flow systeem? Deze werken met de zenders van type 536-0146

Heb je het al geprobeerd?

[Ierlandfan]

Kleine toevoeging op de ESPEasy handleiding Voor iemand (zoals me) die daar niet zo bekend mee is:

Als je de interrupt pin op D1 hebt moet je de I2C Interface even aanpassen naar een andere pin. (BIjvoorbeeld D2 en D12..,iig een ongebruikte pin) Dan kan je een nieuw device toevoegen en bij sensor kiezen voor pin D1. Anders is ie niet te kiezen. Voor de rest werkt het prima. (Nu ook op een Wemos D1)

[jvdzande]

Hoor graag jullie bevindingen!

Dank je voor het delen! Ik ga het op zeker komend weekend testen.
Heb jij hem nu draaien om de Wemos D1 of ander esp?

[jodur]

Ierlandfan schreef op dinsdag 9 januari 2018 @ 20:36:
Kleine toevoeging op de ESPEasy handleiding Voor iemand (zoals me) die daar niet zo bekend mee is:

Als je de interrupt pin op D1 hebt moet je de I2C Interface even aanpassen naar een andere pin. (BIjvoorbeeld D2 en D12..,iig een ongebruikte pin) Dan kan je een nieuw device toevoegen en bij sensor kiezen voor pin D1. Anders is ie niet te kiezen. Voor de rest werkt het prima. (Nu ook op een Wemos D1)

Ok thnx, zal dat in de readme aanvullen.

Ben nu bezig de Fan aan het opnemen in Homeassistant.

Zal het voorbeeld posten!

[ Voor 25% gewijzigd door jodur op 10-01-2018 15:21 ]

[jodur]

jvdzande schreef op dinsdag 9 januari 2018 @ 20:40:

Heb jij hem nu draaien om de Wemos D1 of ander esp?

Ja op een Wemos D1 mini, de intentie was om deze tegelijk met een DHT22 op een wemos te draaien.
Door het beperkte aantal pinnen en de retricties op sommige pinnen t.a.v. interrupts, heb ik de D1 opgeofferd voor de interrupt pin waar normaal de i2c op zit. Heb nog niet uitgetest of de i2c dan op de ander pinnen kan worden gebruikt. zie ook voorgaandeopmerking @Ierlandfan

[ Voor 4% gewijzigd door jodur op 10-01-2018 12:16 ]

[demanditho]

sjimmie schreef op dinsdag 9 januari 2018 @ 18:28:
[...]

Heb je het al geprobeerd?

Yup, met verschillende versies en diverse cc1101. Ik heb een paar nieuwe binnen en wil weer een poging gaan wagen.

[sjimmie]

demanditho schreef op woensdag 10 januari 2018 @ 11:46:
[...]


Yup, met verschillende versies en diverse cc1101. Ik heb een paar nieuwe binnen en wil weer een poging gaan wagen.

Wellicht lost de nieuwe versie van de code eea op.